FAQ.
including the awkward ones

I do. The person you talk to on the first call is the person in your codebase. There is no account manager relaying messages, and no junior quietly picking up the work after the contract is signed. Where a project genuinely needs more hands, I bring in developers from partner firms — and I tell you plainly who they are, who employs them, and you interview them before they start.

Yes. A monthly retainer buys a fixed share of my week, embedded in your team — your standups, your board, your codebase. Interview me first; I would rather you did.

For larger scope, yes — through development firms I have worked alongside. I do not keep a bench on payroll and I will not pretend otherwise. You interview every developer, you are told who employs them, and I stay the technical owner and single point of accountability throughout.

Yes. I sign a mutual NDA, work to your process, and stay invisible to your client. Nothing about the engagement appears on this site or in my portfolio — no case study, no logo, no mention. Your client relationship stays entirely yours.

When you need a vendor with ISO certification or a formal headcount on paper — I am one person and cannot honestly claim otherwise. When you want the cheapest quote rather than the right answer. When the work is a straightforward brochure site, where an agency will serve you better and cheaper. I would rather tell you that on the first call than three weeks in.

Ahmedabad, India. I work remotely with clients in Europe and North America. I mention it up front because you would find out anyway, and because it is not a problem I need to hide — it is a set of hours we agree.

Straightforward. I am 3.5–4.5 hours ahead of the Netherlands and 2.5–3.5 hours ahead of Finland, so a normal European working day sits comfortably inside mine. Overlap is rarely the constraint on European projects.

No — it is included as standard. Before handover I check every third-party dependency against known vulnerability advisories, run static analysis over the code, and review the things that actually break systems: access control, data isolation, how secrets are handled. You get the findings either way. Most agencies bill this separately or skip it entirely.

Yes, around the paths that matter. Not to hit a coverage number — to make sure the thing that must not break, does not break. On a rebuild, tests are usually what makes an incremental cutover possible at all.

No. Those certifications require an organisation and an audit budget that a single engineer does not have, and I am not going to imply otherwise. If your procurement genuinely requires them, I am the wrong vendor and will say so early.

Where the risk justifies it, a separate database per tenant rather than a shared schema with a tenant column. It costs more in migration and connection handling, and it buys a much smaller blast radius, per-tenant backup and restore, and a straight answer when your customer asks whether another customer can see their data.

Yes, before anything is shared. That applies to direct clients and to agencies subcontracting to me.

By finding out whether the project is the right one. Then I measure before I change anything — query counts, slow paths, where the time and money actually go. Those numbers become the baseline we judge the result against at the end.

I do not disappear. You get the person who built it rather than a ticket queue, and software built to keep running without me. If the numbers we measured at the start have not moved, the job is not finished.

Often, yes — it is a lot of what I do. Inherited codebases with no tests, no documentation and an original author long gone are a normal starting point rather than a disqualifier. The first step is always measuring what is actually there, not rewriting it on instinct.