These are the questions that come up most often before a first conversation. If something isn't covered here, the quickest way to get an answer is to use the contact form — I respond to all serious enquiries within one business day.
I'm currently on a 12-month contract with DWP Digital through to September 2026. I'm available for focused freelance work that fits around core hours — evenings and weekends — if the project is well-scoped and suits the arrangement. For a new full-time contract, I'm available from October 2026.
For freelance work alongside my current contract, typically within a week of agreeing terms. For a new contract from October 2026, I can start within 30 days of agreement — often sooner depending on notice obligations at the time.
Day-rate contracts and fixed-scope freelance projects are my primary mode. I also take on consulting and architecture review engagements — where you need a senior eye on your system design rather than ongoing delivery — and technical advisory arrangements. I'm open to longer-term opportunities for the right team and problem.
Yes. Some of my most interesting freelance work has been for small teams and founders who needed senior-level engineering judgment without a full-time hire. I'm comfortable working independently with minimal process overhead, which is often what early-stage teams need. I'm equally comfortable in large enterprise and regulated environments — government, banking, and energy are all on my CV.
Yes. I take on focused consulting and architecture review engagements where a senior eye on a specific problem is what's needed rather than ongoing delivery. If you have a design decision to validate, a system you're concerned about, or a spike that needs a week of focused work, get in touch with the scope and I'll tell you quickly whether it's something I can help with.
It depends on my current commitments. For freelance work alongside my contract, I can usually mobilise within a week for a well-scoped engagement. If you have an urgent requirement from October 2026, I can discuss expedited starts — 30 days is typical but I've started sooner when the situation calls for it. The best thing to do is contact me directly with the details so we can work out what's possible.
Yes — I'm remote-first. I'm based in Chipping, Lancashire and have worked fully remotely for the majority of my career. I can attend occasional on-site meetings where there's a genuine reason, but I don't take on roles that require regular office attendance.
I work outside IR35 through my limited company, Samuel Jackson Ltd, for client engagements where the determination supports it. I take IR35 seriously and expect clients to have performed a proper assessment. For engagements that fall inside IR35, I can discuss umbrella company arrangements — just raise it early so we can agree terms accordingly.
My rate reflects senior UK contractor market rates for Java and Spring Boot specialists. I don't publish a fixed number — it depends on the engagement type, duration, domain, and IR35 status. Get in touch with a brief description of the work and I'll give you a clear figure quickly. I don't waste people's time.
I'm UK-based and work UK hours (GMT/BST). I've collaborated effectively with teams across Europe and the US, and some timezone overlap is fine. I'm not available for engagements that require consistent presence outside UK working hours.
For day-rate contracts, a minimum of four weeks is typical — shorter than that rarely makes commercial sense for either party once onboarding time is factored in. For fixed-scope consulting or architecture review work, I'll consider shorter engagements where the scope is well-defined and the deliverable is clear. If you're unsure whether your requirement is long enough, just describe it — I'll give you a straight answer.
Both. I work directly with clients where possible — it's simpler and removes an unnecessary layer from the relationship. I also work through agencies where they're already embedded in a client's supply chain or where the engagement structure requires it. If you're coming to me via an agency, that's fine — just make sure rate and IR35 status are agreed early.
I adapt to the client's workflow rather than imposing my own. I'm comfortable with Jira, GitHub, Confluence, Slack, and Teams — whatever the team already uses. I attend standups, provide regular written updates, and make myself available during core UK hours. I'm async-friendly and write clearly, which matters more for remote teams than any particular tool choice.
Standard notice for a contract is two weeks unless agreed otherwise. For longer engagements, I'm happy to negotiate a longer mutual notice period if that gives the client more planning certainty. Extensions are straightforward — if the work is going well and we both want to continue, we agree terms and carry on. I don't hold clients to extensions and I don't abandon projects mid-delivery.
Java backend engineering — specifically event-driven microservices with Spring Boot and Apache Kafka, AWS cloud architecture, and real-time data systems. I have 25 years of commercial Java experience across investment banking, financial data platforms, government digital services, energy, and retail.
My most distinctive specialism is betting exchange technology: I've built a production high-frequency trading framework integrated with Betfair's Exchange and Streaming APIs. That combination of Java depth and betting domain knowledge is rare at senior level.
Yes — this is my most specific niche. I've architected and delivered a production-grade, high-frequency trading framework using Betfair's Exchange and Streaming APIs, with automated strategies driven by real-time market signals: Weight of Money trends, Last Traded Price dynamics, price velocity, and order flow imbalance. The architecture is extensible to Betdaq, Smarkets, and Matchbook.
If you're building serious Betfair tooling, I'm one of very few senior Java engineers with genuine production experience at this level.
My focus is backend engineering. I can work in JavaScript and TypeScript and understand frontend concerns well enough to integrate cleanly with frontend teams, but I'm not the right choice if the engagement is primarily frontend or full-stack UI work. If you need the back end built properly and a strong integration contract, that's where I add the most value.
Yes. I've taken on technical leadership throughout my career — owning architecture decisions, mentoring junior and mid-level engineers, running production change management, and providing 3rd-line support. I work well as a senior individual contributor and equally well as the technical lead on a delivery team. If you need someone who will shape how the team works, not just execute tasks, that's something I actively enjoy.
My primary target is Java 17 and 21 — I use modern language features (records, sealed classes, pattern matching, virtual threads) where they genuinely simplify code. I have production experience across Java 8, 11, 17, and 21, and I've worked in codebases that range from actively maintained Java 21 to legacy Java 8 systems that haven't been touched in years.
Modernisation — migrating from Java 8 or 11 to 17/21, upgrading Spring Boot versions, removing deprecated APIs — is work I actively take on. If you have a codebase that needs bringing forward, that's a concrete problem I can help solve.
AWS is my primary cloud platform — I have hands-on production experience with EC2, ECS, EKS, RDS, SQS, SNS, DynamoDB, S3, Lambda, Secrets Manager, and CloudWatch. I've also delivered on GCP (GKE, BigQuery, Cloud Run) and worked with Azure in enterprise environments. I'm cloud-pragmatic rather than cloud-religious — the right platform is the one the client is already on.
TDD where it adds value — which is most of the time for domain logic and critical paths. I write unit tests, integration tests with Testcontainers (real databases, real message brokers), and contract tests with Pact for service boundaries. I treat coverage as a by-product of good test design, not a metric to optimise for.
Code quality is about long-term maintainability: clear naming, small focused functions, consistent patterns, and code review that's about knowledge sharing as much as defect prevention.
I own the delivery pipeline end-to-end where the engagement calls for it — Docker, Kubernetes, GitHub Actions, ArgoCD, and Terraform for AWS infrastructure. I've set up CI/CD pipelines from scratch and maintained them in production. That said, I'm a software engineer first — if a client has a dedicated platform team, I work with them rather than across them. I don't replace a platform engineer, but I don't need hand-holding on the deployment side either.
Yes. You can read what previous clients have said on the Testimonials page. For direct references from specific engagements, mention it when you get in touch and I'll connect you with appropriate contacts.
Yes, standard mutual NDAs are fine. I review contracts carefully and take confidentiality seriously — it's a normal part of working in financial services and government. I expect the same professional discretion in return.
For contracted and freelance work, IP ownership is negotiated as part of the engagement terms. The default expectation is that work delivered for a client belongs to the client — I don't retain rights to client codebases. If you have specific IP requirements, raise them early and we'll make sure the contract is clear.
The contact form is the most reliable route — I respond to all serious enquiries within one business day. You can also email directly at jacksosa76@gmail.com. The more context you give about the project upfront — tech stack, scope, timeline, budget range — the faster we can work out whether it's a fit.
I can work on both. Day rate works well for ongoing delivery and evolving scope. Fixed-price is appropriate for well-defined, bounded deliverables — an architecture document, a proof of concept, a specific integration. For fixed-price work I scope carefully upfront, because the quality of the outcome depends on the quality of the scope definition. If the scope is genuinely fixed, the price can be too.
I front-load onboarding: reading the existing codebase, understanding the domain, getting the local development environment running, attending team ceremonies, and identifying areas of highest risk or technical debt. By the end of the first week I aim to have made at least one meaningful contribution and to have a clear picture of where I can add the most value. I don't spend two weeks asking questions before writing code.
Yes, and meaningfully so — not just Copilot autocomplete. Over the past year I've integrated Claude Code and GitHub Copilot into my core workflow across contract work and personal projects: test generation, code review, design exploration, boilerplate acceleration, and refactoring. The productivity gains are real.
What matters most is the judgment to use these tools well — knowing when to accept a suggestion, when to reject it, and when the model has produced plausible-looking code that's actually wrong. That's where senior experience is the differentiator.
Yes. I've worked directly with the Anthropic Claude API and OpenAI's GPT-4o API, and used LangChain4j — the Java-native LLM framework — to build RAG (Retrieval-Augmented Generation) pipelines. Practical deliverables include: document Q&A over internal knowledge bases, AI-powered search over structured or unstructured data, LLM-assisted extraction from messy inputs, and conversational interfaces layered over existing APIs.
These are standard Spring Boot integrations — vector stores, embedding generation, prompt engineering, and context window management all handled at the application layer.
The same way I review any code — I own what goes into the codebase. AI tools produce a fast first draft; professional judgment determines what ships. In practice: I read every generated block, run the test suite, think about edge cases the model didn't consider, and apply extra scrutiny to security-sensitive code — authentication, secrets handling, SQL — where AI suggestions are most likely to introduce subtle vulnerabilities.
The risk of AI-assisted development isn't the tooling; it's engineers who accept suggestions without understanding them. I don't.
Yes — this is one of the more interesting intersections of my skills. I've used LLM-based analysis to process Betfair historical market data at scale, surfacing strategy patterns that would take weeks to identify manually. I've applied AI tooling to backtesting analysis: summarising outcomes across thousands of simulated markets, identifying where strategies perform well and where they don't.
For trading system development, AI is a genuine productivity multiplier — it handles the volume problem so the engineer can focus on the reasoning.
Senior backend skills — system design, debugging production failures, understanding domain constraints, making architecture decisions that hold up years later — are where experience still matters most. AI accelerates delivery of well-understood code; it doesn't replace judgment about what to build or how to structure a system for long-term maintainability.
In practice I treat it like pair programming with a very fast, confident junior who needs supervision: useful precisely because you know what good looks like.