Working together

What to expect when hiring a solo developer

Published September 7, 2026 · Lefty Software LLC

What should you expect when hiring a solo developer instead of an agency? Lower overhead and total accountability, and in exchange a risk profile you need to manage deliberately: one person's calendar is your project's calendar, and if that person vanishes, the git repo is all that's left. I work as a solo developer, so read this with that bias declared — but this is the process I run and the questions I'd tell any client to ask me before signing anything.

Why people choose a solo developer

The honest pitch is not price. Solo developers are often comparable to small agencies per hour. What you actually buy:

• The person writing the code is in every meeting. Nothing is lost translating your business problem into a ticket, and then again into an estimate. The feedback loop from "that's wrong" to "fixed" is measured in hours, not sprints.
• Nowhere to hide. At an agency, underdelivery is diffused across account managers and resourcing. With a solo developer, the person you talk to owns every outcome, which concentrates both accountability and incentive.
• No handoff tax. Roughly speaking, every boundary between people on a project adds coordination cost. One person, zero boundaries.

The honest cost: capacity and continuity. A solo developer can only do one project's worth of work at a time, and the mitigations for that — which I'll get to — are your responsibility to check, not just theirs to promise.

The process, start to finish

1. Discovery: a conversation, not a form

Expect a 30–60 minute call where you describe the problem you have, not the software you think you need. A good solo developer will poke at scope here — "does this need to exist in v1?" is the most valuable sentence in the whole engagement. Afterward you should receive a short written summary of what was discussed. If there's no follow-up writing, there's no shared record, and memory is not a project plan.

2. A written proposal with a fixed price

The proposal is the most important document of the project: what will be built, what is explicitly excluded, what "done" means, the price, and the timeline. One or two pages. It prevents the large majority of disputes before they exist, and how a developer behaves around it tells you a lot — vague exclusions and verbal promises now are change orders later.

3. A deposit to book real time

Deposits of 30–50% are standard practice for solo developers, and they cut both ways: you've secured a slot on a constrained calendar, and the developer has a client who is invested. The remainder is typically due at milestones or at launch. What you should never accept is 100% up front.

4. Building in reviewable increments

This is where solo developers should shine. Expect a staging URL you can click within the first couple of weeks, updated continuously — not a big reveal at the end. Feedback while a screen is half-built is cheap; feedback after launch is a change request. You should never have to ask what the status is; the staging link is the status.

5. Launch, then handover

Launch is DNS and deployment plus the boring essentials: analytics, error monitoring, backups verified by actually restoring something. Handover deserves its own section below, because ownership is where solo engagements are won or lost.

Timelines you can expect

Typical calendar time for common scopes, assuming a focused engagement:

• A small marketing site or landing page: 1–3 weeks.
• A focused web app or MVP — accounts, a core workflow, email, polish: 6–12 weeks.
• An integration or automation between systems you already run: 1–3 weeks.

Ask one clarifying question about any timeline: is this calendar time or effort time? A solo developer usually runs two or three clients in parallel unless you've agreed on exclusivity, and both arrangements are fine — but they produce very different delivery dates from the same effort estimate.

Money and change requests

New projects are fixed-price. Changes and maintenance can be provided at an agreed hourly rate. Website projects include 30 days of support for defects and questions after the website goes live; monitoring is available if purchased separately. The written change request keeps work outside the proposal explicit: you get an estimate of its cost and timeline effect before it starts. Approve it or don't — but never discover it on an invoice. And ask directly: "what happens if your estimate turns out wrong?" For a fixed price, the right answer is "that's my risk; that's what the fixed price means." A developer who scopes accurately absorbs the occasional miss as the cost of their own education.

Ownership: the part that matters most

Here is the standard I'd insist on from any solo developer, and the one I hold myself to: from day one, everything lives in accounts you own. The code repository is in your GitHub org or yours alone. The domain is in your registrar account. The cloud provider, the email sending, the analytics — your accounts, or at minimum documented and transferable within a day. The contract should state that work product is assigned to you on payment. If a developer insists the code "lives on their server," walk away; that is not a developer, that is a hostage situation with invoices.

At handover you should receive: a README that gets a competent stranger running the project locally, a one-page architecture summary, a deploy runbook, and where every credential lives (in your password manager, not theirs). The test of a real handover: could a different developer take over with a week of reading and no phone calls to the person who left? If yes, you hired well regardless of how the project ends.

Managing the one-person risk

The bus factor of one is the real objection to solo developers, and it deserves a straight answer rather than reassurance. You manage it with structure, not hope:

• Boring, standard technology. A mainstream stack means thousands of developers could continue the project. A solo developer's exotic pet framework means only they can.
• Your accounts, from day one. Covered above, because it is the single highest-leverage protection. Ownership is continuity.
• Documentation as a deliverable, in the contract, accepted like a feature.
• Due diligence you can verify. Click shipped products, not mockups. Ask what happened to past clients when the engagement ended. Ask what the handover pack contained.

When a solo developer is the wrong choice

Plenty of situations are: you need a contractual 24/7 response SLA; the project needs three specialists working in parallel for months; your compliance regime demands organizational process a single person cannot evidence; or the product's success depends on a design system only a dedicated team can maintain. A good solo developer will tell you when they're the wrong tool — I've done it, and it buys more trust than any project ever has.

If the fit is right, the experience is hard to beat: you describe a problem to the person who will solve it, you watch it appear on a staging link every week, and at the end you own every piece of it. That's the engagement I run — the products you'll find in my portfolio were all built this way — and if you're weighing costs first, start with what a custom web app costs in 2026.

← More from the blog