How I work with clients

Have you built something like what I need?

Probably some of it, and I will tell you plainly which parts are new to me. Nobody has built your exact product, and a developer who claims otherwise is telling you what you want to hear.

What I have shipped: a payment gateway with multi-bank integrations and fraud handling, a real-estate CRM with omnichannel messaging, an AI video pipeline with distributed rendering workers, and a distributed task management system. Each of those case studies is on this site, including what was hard about them.

On the first call, ask me which of your requirements I have done before and which I have not. The answer to the second half is the one worth listening to.

Do you handle UI/UX, frontend, backend, database and deployment?

Frontend, backend, database, infrastructure and deployment — yes, all of it, and that is the point of hiring one experienced generalist rather than coordinating four specialists.

Interface design: I build clean, conventional, accessible interfaces and have designed plenty of them myself. I am not a brand designer. If your product needs real visual identity — distinctive art direction, illustration, motion — hire a designer for that and I will build precisely against their files. I will tell you up front which of those two situations I think you are in.

Do I own the source code and the repository?

Yes. Completely, and in writing.

The repository lives under your GitHub organisation from the first commit wherever possible, so you can see the work as it happens rather than receiving a zip file at the end. Intellectual property in the delivered work transfers to you as each milestone is paid.

There is no license-back, no proprietary framework you would have to keep paying me for, and no component that stops working if we part ways. Infrastructure runs in your cloud accounts, not mine, so you hold the keys to your own servers and data.

• Repository under your organisation, from the first commit
• IP transfers to you on payment of each milestone
• Cloud accounts, domains and third-party services in your name
• No proprietary lock-in and no license-back clause
• Documentation written so another developer can take over

What technology would you recommend, and why?

I will give you a specific recommendation with reasoning, and the reasoning matters more than the answer.

My defaults are TypeScript across the stack, Next.js and React on the frontend, Node.js with NestJS or Python with FastAPI on the backend, and PostgreSQL for data. Not because they are fashionable, but because they are boring, well-documented, and hire-able — you can find another developer who knows them.

That last point is the one most technology decisions get wrong. Picking a stack your future team cannot hire for is a strategic mistake dressed up as a technical preference. If your team already knows a different mainstream stack, that usually outweighs my preference and I will say so.

Do you write tests and handle security?

Tests on the paths where a bug costs real money — payments, authentication, data integrity, anything with a webhook — running in CI on every push. I do not chase a coverage percentage across the whole codebase, because that spends your budget writing tests for code that was never going to break.

Security is the standard discipline applied consistently rather than anything exotic: input validation at the boundary, parameterised queries, secrets in environment configuration and never in the repository, dependency scanning in CI, least-privilege database credentials, and rate limiting on anything public.

What I will not do is claim a formal compliance certification. If you need SOC 2, ISO 27001 or a PCI audit, you need an auditor as well as an engineer, and I will tell you that rather than let you assume otherwise.

What happens when something breaks after launch?

Bugs in work I delivered are fixed free within the warranty window after each milestone ships. That is a defect in what I built, not a new project, and you should not pay twice for it.

Beyond the warranty window, most clients move to a monthly retainer covering fixes, dependency updates and small features. It is optional. You can take the codebase in-house or to another developer — it is written and documented on the assumption that one day you will.

For genuine outages we agree a response time in advance, matched to what your product actually needs. I will not promise a fifteen-minute response as a solo engineer, because I could not keep it and you would discover that at the worst possible moment.

Do you work milestone by milestone?

Yes, and I would push back if you suggested otherwise. Milestones protect both of us: you are never far from something you can evaluate, and I am never far from being paid.

Each milestone ends in working software on a staging URL you can click through, not a status document. You approve it, you pay it, we start the next one. If you want to stop after any milestone, you stop — and you keep everything built so far, including the repository.

Typical structure is a deposit to start, then payment per milestone, with milestones sized to one or two weeks. Long milestones hide problems; that is exactly why some agencies prefer them.

• Scoping call and written proposal — free
• Deposit to reserve time, then payment per completed milestone
• Every milestone deployed somewhere you can use it
• Stop after any milestone and keep everything built so far

Will I speak to the person actually writing the code?

Always. There is nobody else — that is the main structural advantage of hiring me over an agency.

At an agency, the senior engineer who impresses you in the sales call is often not the person assigned to your project, and your requirements pass through an account manager and a project manager before reaching a developer. Every hop loses detail. You find out months later, when what arrives is not what you described.

With me the person you scope with is the person who writes it and the person who fixes it at 11pm. That is also the honest limitation: I am one person, so I cannot field a team of five next week. When your project genuinely needs that, I will tell you and help you brief an agency properly.

What does it cost and how long does it take?

Cost is driven by scope, and scope is the thing worth spending time on before anyone quotes.

Engagement models: fixed price for well-defined scope, hourly for exploratory or open-ended work, monthly retainer for ongoing support. Fixed price gives you certainty and gives me an incentive to be efficient — it works when we can define the scope properly, which is what the free scoping call is for.

As a rough guide on timelines: a focused SaaS MVP is typically eight to sixteen weeks, a payment or third-party integration one to five weeks depending on complexity, and a performance audit three to five days. After the scoping call you get a written milestone breakdown with dates and a number, not a range.

I quote per project after scoping rather than publishing a rate card, because a number without scope is meaningless in both directions. Ask on the first call and you will get a straight answer, not a bracket that widens later.

When should I hire an agency instead of you?

When you need several people working in parallel to hit a fixed external deadline. When you need design, mobile, backend and QA simultaneously. When your procurement process requires a company with insurance, a legal entity of a certain size, or a bench of developers for continuity.

Those are real reasons and I will say so rather than take a project I should not. What I would push back on is hiring an agency purely because a solo developer feels risky — the mitigation for that risk is code you own, infrastructure in your accounts and documentation you can hand to anyone, all of which I do by default. Ask any developer how they would leave your project. The answer tells you a lot.