Your Codebase Is Not a Sacred Temple

The pull request sat open for eleven days. I had finally admitted I could not ship the Stripe webhook fix and the onboarding rewrite in the same week without letting support tickets rot. So I hired help. Smart hire, everyone said. Great portfolio. Then silence. Commits on Sunday night. Vague Slack messages. The webhook still failed at 2 a.m., just with someone else's signature on the broken middleware.

I merged nothing. I rewrote it myself on a Thursday. Lost six hundred dollars and three weeks of momentum. The lesson was not "never hire." It was that I hired before I could describe the job, before I had revenue to absorb a miss, and before I had a trial task that would have exposed the mismatch in forty-eight hours.

Most advice on how to hire a developer for a micro-SaaS as a solo founder assumes you are a non-technical CEO with a pitch deck. You are not. You are probably the person who validated, built v1, wired Stripe, and answered support at lunch. Delegation is not abdication. It is a growth-stage skill you pick up when your product earns the right to borrow someone else's Tuesday.

This post is for that moment. Not "how to find cheap devs overseas." Not "scale to a team of twelve." When your MRR covers ramen plus one contractor, when the backlog has one scary item you keep deferring, when you need to outsource micro-saas development without handing over the company. I will talk money thresholds, contract shapes, where to look, how to run a paid trial, and what to keep building yourself. Bootstrapping means you still own the repo when the retainer ends.

If you have not launched yet, close this tab and read how to launch a micro-saas instead. Hiring before customers is how founders burn savings on a codebase nobody pays for. Hiring after customers, with a scoped problem, is how solo founders buy back hours without buying a second job as project manager.

The uncomfortable truth is that most solo founders wait too long on the wrong work and too early on the wrong help. They grind for three weekends on a CSS tweak while an enterprise trial waits on SAML. Or they hire a team before anyone has renewed a subscription. Both mistakes share the same root cause: no written definition of what matters this month. Fix that definition and hiring gets simpler. You are not looking for a magician. You are looking for a senior pair of hands on one ugly ticket while you keep the rest of the company alive.

How to hire a developer for a micro-SaaS as a solo founder

There is a week I remember more clearly than most launches. Fourteen trial signups. Three billing bugs. A customer asking for SAML before I had fixed password reset. I was the entire engineering org, support desk, and marketing department. Something had to give, and what gave was sleep. That is usually when founders start googling how to hire a developer for a micro-SaaS without giving away the company.

Delegation is not optional when you are choosing between bad options: ship nothing, ship broken, or let growth stall. It is optional — and usually a mistake — when you are bored, intimidated by one library, or want someone to "take over tech" so you can do strategy theater. Strategy is picking which bug kills revenue fastest. Everything else is procrastination with a LinkedIn job post.

I use a simple gate before I spend a dollar on outside help. Paying customers exist. The task is written in one paragraph a stranger could execute. The task connects to revenue or retention, not vanity. My MRR can absorb the cost without skipping ads or rent. I can review a pull request in an evening. If any of those fail, I keep solo building or I cut scope.

Solo founder delegation is not about escaping code. You will read diffs forever if you own the product. It is about buying focused execution on the slice you are slowest at, while you stay on the parts only you can do: talking to users, pricing experiments, the weird product calls that do not fit a ticket.

The founders who regret hiring usually skipped the gate. They outsourced "the app" before pricing was settled. They hired a rewrite when they needed a patch. They confused activity with progress because someone was committing code somewhere. Commits are not MRR.

You can stay solo longer than Twitter implies. AI tooling in 2026 lets one developer punch above 2018 headcount. But there is a ceiling. Webhook idempotency at scale. Mobile parity. Accessibility audits for enterprise deals. A security review before a hospital will trial. Those are legitimate when to hire contractor saas triggers. "I do not feel like learning CSS grid" is not.

Ask yourself what happens if this task slips four weeks. If the answer is "nothing measurable," do not hire. If the answer is "churn spikes" or "we lose the pilot," hire with a brief and a trial.

The tasks I outsource first versus the tasks I never hand off early

My first outsourced jobs are almost always unglamorous. A race condition in the job queue. A missing database index on the export screen that times out for customers with big accounts. Wiring the Customer Portal link because I keep putting it off. These are outsource micro-saas development wins: bounded, testable, and obviously connected to someone paying or someone leaving.

I do not outsource greenfield features that change positioning. Not the new dashboard. Not the AI summary block I dreamed up on a walk. Not "build me a mobile app" when web MRR is still the whole business. Those need customer evidence first, usually from you, usually in a spreadsheet or a pile of support tags.

There is a middle category that tempts people: refactors. "Clean up the codebase so we can move faster." Refactors without a performance or security trigger are often expensive therapy. If a contractor proposes one unprompted, ask what user-facing metric moves. Silence means defer.

What you are actually buying when you hire help

Founders talk about hiring a developer the way they talk about hiring a plumber. Pipe's broken, person fixes pipe, invoice, done. Software is messier. You are buying hours of judgment applied to an ambiguous system you built at 11 p.m. without comments. The contractor does not inherit your mental model. They reverse-engineer it from Git blame and hope.

What you buy: implementation speed on a defined slice, specialized knowledge you do not want to acquire (tax API quirks, SAML, video encoding), and calendar relief. What you do not buy: product taste, customer empathy, or automatic alignment with your onboarding philosophy. Those stay yours unless you write them down and enforce them in review.

I think in three buckets when I scope outside help.

Execution bucket. The path is clear. Migrate this table. Add this webhook handler. Build this export job. Success is binary. Low communication overhead. Best first hire shape.

Architecture bucket. The path is debatable. Multi-tenant isolation. Real-time sync. Caching strategy before traffic spikes. You need someone senior who will argue with you. Pay more. Review more. Still cheaper than learning distributed systems during a launch week.

Discovery bucket. "Figure out why signup conversion dropped." That is not a contractor task unless you hire a product engineer and give them analytics access plus user interview notes. Most solo founders accidentally buy discovery when they meant execution. Discovery without a founder in the loop produces elegant code solving the wrong problem.

The invoice line says "40 hours." The real purchase is risk transfer. You risk cash instead of time. Cash is finite. So is reputation with paying users. A bad contractor spends both.

When Imani writes about tools for non-developers, the promise is you can ship without reading every file. Hiring is the next layer: someone reads the files for you, but you still sign the merge. Non-technical founders sometimes hire to avoid learning. Technical founders sometimes refuse to hire because learning is their identity. Both can be wrong. The question is opportunity cost at your current MRR, not ego.

The revenue threshold I use before I outsource anything

Numbers vary by rent and geography. Principles travel. I will use round illustrative figures, not my bank statement.

Say your product cleared two thousand dollars MRR. You are past "is this real?" and into "can I afford to not fix the scary bug?" A senior freelance retainer at three thousand dollars a month would consume more than your revenue. That is not delegation. That is subsidizing development with savings or a day job. Fine if you choose it consciously. Fatal if you pretend revenue supports it.

My informal rule: monthly contractor spend should stay at or below ten percent of MRR for ongoing help, unless the project is a one-time unlock (enterprise feature that closes a twelve-thousand-dollar annual contract). Track the ratio with an MRR calculator when you are debating whether a retainer fits current revenue. For a bounded project, cap exposure at one month of MRR. If the quote exceeds that, shrink scope or wait.

At five thousand MRR, a three-week project billed at four thousand dollars stings but is survivable if the feature reduces churn or closes a segment you have been chasing. At eight hundred MRR, the same project is a bet on future revenue that may not arrive. I have made that bet. Sometimes it worked. More often I wished I had spent the four thousand on cold email to ten more qualified accounts instead.

Cash runway matters as much as MRR. MRR is optimistic. Runway is honest. If hiring leaves you three months of expenses and zero buffer for Stripe disputes or a laptop dying, wait. Contractors are not employees. No unemployment insurance when you pause the retainer.

Track the ratio on a sticky note if you need the reminder. Retainer divided by MRR. Above 0.15 for more than one month, I audit what the contractor shipped that customers noticed. Sometimes the answer is "nothing users could name," which means I mis-scoped or mis-hired.

Equity is a separate conversation. For micro-SaaS solo founders, I default cash-for-work. Equity muddies exit math on a product that might never raise. If a contractor asks for points on a five-thousand-MRR tool, I explain they are underwriting my marketing risk with their discount rate. Usually we agree on cash or we part ways. Exceptions exist for true cofounder-shaped relationships. That is not your first contractor.

A quick sanity table before you sign

Say you are at four thousand MRR and considering a six-week project quoted at five thousand dollars flat. That is more than one month of revenue for one feature. Justified only if you can name the customer or churn event it unlocks. Say you are at nine thousand MRR and considering ten hours a week at seventy-five dollars an hour for six weeks. That is roughly three thousand dollars a month, about a third of MRR, high but survivable if you are not also running ads and you expect support load to drop when the work ships.

I write the expected outcome on the same sticky note as the ratio. "Close Acme pilot" or "Cut billing tickets in half." If I cannot write an outcome, I do not write a check.

Freelance, agency, or fractional CTO — pick the wrong shape and pay twice

The market offers three shapes that solo founders confuse constantly.

Freelancer. One person. You write scope. They execute. Lowest overhead, highest variance. Best when you can review code and the task fits four to six weeks. Worst when you need daily standups across time zones and you have never managed anyone.

Agency. Team behind a brand. Account manager, maybe. Higher cost, more process, more predictable staffing. Best when you need design plus dev plus QA in one invoice and you hate coordinating individuals. Worst when you are paying for their sales team while your product has twelve users.

Fractional CTO / product engineer. Senior person, few hours a week, strategic plus hands-on. Best when architecture is the bottleneck and you trust them to say no to bad ideas. Worst when you need forty hours of typing and they give you twelve hours of diagrams.

Most first hires should be a freelance developer solo founder relationship: one senior engineer, bounded brief, merge into your repo. Agencies shine later, when you have parallel workstreams and support load that justifies project management tax. Fractional CTOs shine when you are non-technical or when your codebase is a liability and you need someone to tell you a rewrite is stupid.

I have watched founders hire agencies to avoid writing a brief. The agency fills the vacuum with their template stack, ships something that demos well, and leaves you with dependencies you did not choose. I have watched founders hire cheap freelancers to "save money," then spend twenty hours debugging minified jQuery plugins. Savings are fake if your hourly rate as founder-support-engineer is higher than theirs.

Timezone overlap beats rate cards. A mid-rate developer who answers during your morning beats a cheap genius who commits at 3 a.m. your time with questions you see after customers complain. Async can work. Silence cannot.

Red flags in the first call: they promise full rebuild in two weeks, they will not work in your repo, they insist on proprietary hosting, they dodge IP questions, they have never shipped subscription billing. Green flags: they ask what stack you use before quoting, they want to see the worst file in the codebase, they suggest shrinking scope, they have a public trail of small shipped products or honest case studies without fake logos.

Write a brief a contractor can execute without guessing

If you cannot describe the done state, you are not ready to hire. Not because contractors are picky. Because ambiguity becomes their license to interpret, and interpretation favors their habits, not your customers.

My one-page brief template has six blocks. I paste it into Notion or a GitHub issue every time.

Context. Two sentences. What the product does, who pays, link to staging. No origin story.

Problem. One paragraph. What is broken or missing, with a user-visible symptom. "Enterprise prospect needs SAML" beats "improve auth."

Done definition. Bullet list of observable outcomes. "User can connect Okta test tenant. Session persists across refresh. Logout clears SAML session." If you cannot test it, do not list it.

Out of scope. Equally important. "No SCIM. No custom IdP UI beyond Okta and Google. No redesign of settings page."

Stack and access. Repo link, framework versions, how to run locally, test account credentials in a secrets doc. If setup takes more than thirty minutes, fix docs before hiring.

Timeline and budget. "Target merge by date X. Budget cap Y. Paid trial task Z first."

Attach screenshots, Loom links, support ticket quotes. Founders underestimate how much contractors guess wrong from prose alone.

When you hire a developer for a micro-SaaS you still own, the brief is the contract's soul. Legal paper matters. Clarity matters more. I once saved a project by adding an out-of-scope line after a contractor started refactoring my entire API "while they were in there." Scope creep is the tax on vague asks.

Store briefs in the repo under /docs/contractors/ or similar. Future you will forget what "phase two" meant. Git history beats Slack scroll.

Where to find a developer who has shipped small SaaS before

Platforms are interchangeable if your filter is good. Your filter is usually bad.

I start with referrals from other solo founders in the same revenue band. Not Twitter influencers. People who have actually paid an invoice and would hire again or warn me off. Indie Hackers comments, niche Discords, alumni of products I respect. One warm intro beats fifty cold applications.

When referrals dry up, I use specialized marketplaces and senior freelance boards where profiles show shipped work, not buzzwords. I avoid open job posts on general boards unless I enjoy reading three hundred copies of "Dear Sir, I am expert in all technologies." If you post publicly, add a filter question that requires a specific sentence about your product. Mass applicants will not read it.

Look for evidence of small SaaS shapes: Stripe objects in public repos, subscription middleware, webhook handlers, migration files, sane README setup steps. Portfolio sites with only marketing landings tell you nothing about maintaining a product for eighteen months.

Geography is not morality. Communication is. I have great contractors on three continents and bad ones next door. Judge response time on a paid trial, not accent.

Budget reality check for 2026: senior independent contractors who understand billing, auth, and deployment are not fifteen dollars an hour. They are also not agency rack rates. Expect project quotes in the mid four figures for meaningful features. If someone quotes five hundred dollars for "build my entire SaaS," you are not hiring a developer. You are buying disappointment wholesale.

Questions I ask on the first call

I do not grill people for an hour. I ask six things and listen to how they answer.

What is the smallest slice of this you would ship in week one? Good answers name a PR. Bad answers name a discovery phase.

Show me something you maintained for a year, not just launched. Maintenance reveals taste.

How do you prefer to communicate blockers? Daily async message beats weekly surprise.

Will you work in my repo from day one? No means friction later.

What happens if we stop after the trial? I want clean handoff language early.

What would you refuse to build? Seniors have lines. "Anything" is a warning.

Their questions back matter too. The best contractors ask about your test suite, your deploy process, and whether billing is live. The worst ask only about budget and timeline.

One more filter that sounds soft but is not: do they respond to the brief in writing before the call ends? Summarize scope back to you in an email. Misspell your product name. Ignore the out-of-scope section. All small data points. Hiring is pattern matching under uncertainty. You will never have perfect information. You can have a paper trail.

The paid trial task that tells you more than a portfolio

Portfolios lie gently. Trials tell the truth loudly.

Before any multi-week engagement, I pay for a real task from the backlog. Four to eight hours. Production branch. Same tools as the main job. Examples that worked for me: fix a flaky test suite gate, add idempotency to one webhook path, implement a missing index on a slow query customers triggered, wire a small Customer Portal link.

What I watch: Do they ask clarifying questions early or disappear for days? Does the PR description explain tradeoffs? Do they touch only scoped files? Do tests run? Do they respond to review comments same day? Do they document the one weird env var?

I do not use algorithm puzzles. I do not use unpaid "take home" projects that consume a weekend. Pay for their time. Respect breeds honesty. Unpaid trials attract people with free time, not necessarily skill.

If the trial fails, I pay the invoice, archive the branch, and move on. Sunk cost of five hundred dollars beats sunk cost of five thousand. Founders romanticize "giving them another chance." Another chance is a new paid task, not an extended leash.

Share access gradually. Read-only repo first. Branch permissions before production secrets. Production deploy keys only after trust. Paranoia is compatible with friendliness.

Contracts, IP ownership, and the clauses I refuse to skip

I am not a lawyer. This is not legal advice. This is what I insist on before money moves, and what I have learned from messy endings.

Work product goes to you. Written assignment or work-for-hire language in a simple contract. Code lives in your GitHub org. Contractor gets a personal fork only if you are comfortable; I prefer they never host canonical code.

Payment tied to milestones. Trial paid upfront. Larger projects split: start, midpoint demo, merge. Final tranche after production deploy or your acceptance checklist. No "pay everything on day one" unless you enjoy negotiating from weakness.

Confidentiality both ways. They see customer data in staging. You see their rates. Standard NDA is fine for micro-SaaS scale.

Termination clause. Either party can end with one week notice. You pay for hours worked. They hand over work in progress. No hostage branches on their laptop.

No hidden subcontractors without disclosure. If they offshore silently, you want to know because support questions will surface at odd hours.

Tooling costs are theirs unless agreed. Their ChatGPT Plus is not your invoice line.

Keep paper even for friendly referrals. Friends become strangers when a bug costs a customer. Paper keeps friendships recoverable.

Invoicing and taxes without pretending to be finance

You are not HR. You still need clean records. I pay contractors through platforms that issue 1099s when US rules apply, or wire plus a simple invoice PDF when the relationship is direct. Invoice should match the milestone, reference the brief or issue number, and list hours if time-and-materials. I file the PDF in the same folder as the contract. Come tax season you will not remember who "Alex Dev" was.

For international hires, expect currency friction and occasional transfer fees. Budget them. A fifty-dollar wire fee on a four-hundred-dollar trial is part of the cost of learning the person is wrong for you. Cheaper than a lawsuit you will never pursue anyway.

Working with a contractor without becoming their project manager

The hidden tax of hiring is not the Stripe transfer. It is your calendar.

Set a weekly thirty-minute sync maximum for project work. Async daily updates in three sentences: yesterday, today, blockers. Use the same issue tracker you use for yourself. If they only update Slack DMs, you will lose context when you hire person two.

Define review SLAs on your side. If you take six days to review PRs, you are the bottleneck you hired to remove. Block an hour twice a week for diffs. Skim like you care, because customers will live with what you merge.

Resist the urge to micromanage implementation if outcomes are met. Fight for readable code and tests on critical paths. Let them pick variable names unless your linter already cares.

When something feels wrong, name it early. "This PR is bigger than we scoped" is a conversation, not an attack. Contractors are not mind readers. Founders who ghost instead of talking end up with rewrite wars.

Document decisions in the PR or a short ADR file. Your future contractor will not read Slack from March.

If you are spending more time coordinating than you would spend coding the task, the scope is wrong or the hire is wrong. Both happen. Shrink scope first. Replace hire second.

Tools that keep async sane

I keep it boring. GitHub issues or Linear for tasks. One Slack channel or email thread, not six. Loom for "this bug reproduces like this" when typing fails. Staging environment that mirrors production enough to test billing. A /docs/onboarding.md in the repo that contractors update when they find a setup gap, so the next person does not repeat the same question.

Calendar invites for the weekly sync, with an agenda doc linked. No agenda, cancel the meeting and write three bullets async instead. Meetings expand to fill ego. Bullets respect everyone's time.

What to keep building yourself after you hire help

Delegation is selective forever at micro-SaaS scale. Some lanes stay founder-owned because they are the product.

Customer conversations. Nobody else should define what "done" means for angry user number seven. Read support. Join calls. Contractors fix tickets; you fix positioning.

Pricing and packaging experiments. A contractor can implement new Stripe prices. They should not decide your pricing strategy without you in the room.

Core product bets. The feature that changes who buys should not be entirely outsourced until you have a technical partner you would marry (metaphorically). Tactical fixes, yes. Vision, no.

Analytics interpretation. They can wire PostHog. You decide what funnel step matters this month.

Launch moments. Landing page copy, launch email, first-touch onboarding copy. Contractors can implement components. Voice is yours.

Keep your hands in the codebase enough to spot rot. Weekly skim of merged PRs. Run the app locally after big merges. If you cannot boot the project, you have outsourced too much.

AI assistants fill the gap between solo and hire for many tasks. Cursor can draft boilerplate you would have given a junior. That does not replace a senior on a gnarly integration. It does replace hiring someone to generate CRUD you could ship in an afternoon. Use AI before you use invoices when the task is teachable and low risk.

The sequence I see work: you ship alone until a specific ticket blocks revenue. You try AI on the ticket for a day. If it is still stuck, you write the brief. If the brief is clear and MRR supports it, you run the paid trial. If the trial passes, you extend scope in writing, never verbally. Skipping steps is how you end up with a contractor who "owns the backend" while you own the support queue.

When the hire goes wrong (and how to cut losses fast)

It will go wrong sometimes. Not because you are bad at judging people. Because software is uncertain and incentives misalign under pressure.

Warning signs: missed dates without early warning, PRs that rewrite unrelated modules, refusal to write tests on billing code, disappearing for long stretches, defensiveness when you ask for smaller diffs, new dependencies you did not approve, "just trust me" on security-sensitive areas.

When you see a pattern, stop adding scope. Finish or kill the current milestone. Do not fund "phase two" hoping personality will improve. Personality does not improve because you doubled the budget.

Rollback plan before you start. Feature flags. Branch deploys. Database migrations reversible when possible. Contractors have less emotional attachment to your uptime than you do.

If you must terminate, be direct and pay what you owe for accepted work. Retrieve assets same day: repo access, env secrets rotated, documentation of half-finished state. Customers do not care about your HR drama. They care that login works.

Postmortem privately. Wrong scope? Wrong seniority? Wrong communication rhythm? Adjust the brief template, not just the vendor list. I keep a one-page "hires" doc with names, what worked, what failed, never public. It saves repeating mistakes.

The merge you should not be afraid to make

Founders sometimes avoid hiring because they fear losing control of the codebase. Control is not typing every line. Control is merge rights. If you cannot read a diff, learn enough to read diffs on the files that touch money and auth. You do not need to master their framework trick. You need to spot "this deletes the users table" energy.

I treat contractor PRs like external contributions to an open source project you maintain. Courteous review, clear requests, merge when tests pass and scope matches. Revert when they do not. Git is the undo button. Use it without drama.

Questions I get about hiring a developer for micro-SaaS

When should a solo founder hire their first developer?

After you have paying customers, a clear bottleneck you cannot fix in a focused week, and enough recurring revenue that a contractor retainer does not threaten runway. A common rule of thumb is MRR at least ten times your monthly contractor cost. If hiring help would pause marketing or support for a month, you are probably too early. Validate and launch first. Hire when growth is blocked by a specific technical task, not when you are bored of your own code.

How much does it cost to hire a developer for a micro-SaaS?

Scoped project work for solo founders often runs two thousand to eight thousand dollars for a bounded feature. Senior freelance retainers commonly land between twenty-five hundred and five thousand dollars per month for part-time help. Agencies cost more and add overhead. Budget for a paid trial task of four hundred to eight hundred dollars before any larger engagement. The real cost is not the invoice. It is your time managing the relationship and the risk of shipping the wrong thing.

Should I hire a freelancer or an agency for my first contractor?

Freelancer for one bounded project with a written brief. Agency when you need a team shape you cannot coordinate yourself and you have budget for markup. Most solo founders at first hire stage need one senior person for four to six weeks, not a five-person pod. If you cannot write a one-page scope, you are not ready to hire anyone yet. Fix the scope first.

How do I make sure I own the code a contractor writes?

Use a contract with explicit work-for-hire or IP assignment language, require delivery through your GitHub repo with you as owner, and never pay final milestone until code is merged and documented. Avoid open-ended retainers without weekly deliverables. If a contractor refuses IP assignment or insists on keeping code in their own infrastructure, walk away. Your product is the repo. Protect it like revenue.

What should I outsource first as a solo founder?

Outsource work that unblocks revenue or reduces support load, not work that expands surface area. Good first projects: payment edge cases, auth hardening, export pipelines, performance fixes on your hottest path, or a mobile-responsive redesign of one critical page. Bad first projects: rebuild the entire stack, add three new integrations nobody asked for, or greenfield features you have not validated. Stabilize what pays before you decorate.

How do I test a developer before a big contract?

Pay for a small real task from your backlog, not a whiteboard puzzle. Four to eight hours of paid work on production-adjacent code tells you communication, code quality, and whether they read your brief. Review the pull request like you would your own. If they miss deadlines on a tiny task, they will miss bigger ones. Cut fast. Sunk cost is cheaper than a month of silence.

You still own the product — that is the point

Hiring a developer does not make you a CEO who waves at architecture diagrams. It makes you a founder with more calendar and the same accountability. The customers still email you. Stripe still pings your webhook at 2 a.m. The churn still shows up in a dashboard you check before coffee.

Done right, your first contractor buys a month of forward motion on the thing that was blocking revenue while you keep talking to humans who pay. Done wrong, it buys a merge conflict with your savings account.

I still default solo until the math and the brief say otherwise. That is not heroics. It is bootstrapping. Revenue first. Scope on paper second. Paid trial third. Then a check that does not pretend to be an investment round.

Your codebase is not a sacred temple. It is a tool that earns or does not. Hire when the tool needs a specialist's hands and your hands are better on the customer. Keep the keys anyway.