--- slug: hire-first-contractor title: "When (and Whether) to Hire Your First Contractor for Your Indie App" excerpt: "Hiring your first contractor for an indie app is the point where 'I'll do it myself' stops being the cheapest option. Here's how to know, what to outsource first, and the trap to avoid." primaryKeyword: "hire first contractor indie app" publishedAt: 2026-09-06 readingTimeMin: 8 author: "Robert Boylan" tags: - hiring - contractors - solo-founder - indie-dev - scaling --- You've been a solo founder for fourteen months. The app has 300 paying users. You ship features, answer support, write the blog, run the ads, fix the bugs, and remember the domain renewal. Every Saturday you tell yourself you'll get a real day off this week. You haven't yet. The instinct is to keep going alone. "I built this myself, I can run it myself." That's true for a while; it's also the way many indie apps quietly stall around the year-two mark, with the founder burned out, no longer enjoying it, and unable to ship the things that would get the product to the next stage. There's a moment where hiring your first contractor for an indie app stops being a luxury and starts being the cheaper option. This post is about how to recognise that moment, what to actually hand off, and the mistake most indie founders make on their first hire. ## The four signs you're ready You're ready to hire when at least three of these are true. **1. You have a paying customer base.** Not a waitlist. Not "interest." Real recurring revenue. A reasonable threshold is something like $3,000 to $5,000 monthly recurring revenue (MRR), but the number isn't sacred; it's about being able to honestly pay someone for a few months without panicking. **2. There's a clear, describable bottleneck.** Not a vague "I'm overwhelmed." A specific thing you can describe in a paragraph: "I spend 8 hours a week writing blog posts and they're the best traffic source, but the writing eats the time I'd use to ship features." If you can't write the bottleneck in three sentences, hiring won't help yet because you won't be able to brief the contractor either. **3. The bottleneck has been the bottleneck for at least a month.** Some bottlenecks are temporary. The launch surge of support tickets fades. A particular feature push has a deadline and then ends. Don't hire for a bottleneck that's about to resolve itself. **4. You can describe what "done" looks like for the work.** If the work is "do social media," that's not done-able. If the work is "draft and schedule 12 LinkedIn posts a month following this voice doc, with topics from this content calendar," that's done-able. The clearer the definition of done, the less time you spend managing the contractor. If two of the four are true, wait a month and reassess. If three or four are true, the math probably favours hiring; here's what to actually hire for. ## What to outsource first (and what to keep) The mistake most indie founders make is hiring a developer first. It feels right (the product is the heart, surely a co-developer is the biggest help), and it's almost always wrong on the first hire. The first hire should usually be one of these: **A content writer / SEO contractor.** If you're getting any meaningful organic traffic from the blog, doubling down on it is one of the highest-return moves in indie SaaS. A part-time writer who can match your voice (or close to it) and ship 4 to 8 posts a month frees the equivalent of a part-time day for you. Find one through Twitter, Indie Hackers, or word of mouth; check 2 to 3 sample pieces in your voice before committing. Brief: clear topic list, brand voice doc, target audience, internal-linking style. **A paid ads contractor.** If you've validated that ads can profitably acquire customers (and most indie devs haven't, so this is contingent), a part-time ads contractor running Meta or Google can scale that channel while you build. Brief: target CPA, current campaigns, brand voice, what not to say. **A designer for marketing and UI polish.** Not a designer for the whole product. A designer for the things that make the product feel cared for: landing page, OG images, in-app empty states, illustrations, the bits an AI tool can't reliably get to "designed-by-a-human" quality. Brief: brand assets, voice, current screenshots, what feels off. **A virtual assistant for the operational sprawl.** Renewing subscriptions, expense reports, scheduling meetings, basic email triage. The least sexy hire and often the highest hourly ROI. Brief: a list of the recurring tasks, the tools used, the accounts they need access to. What to keep doing yourself, at least at first: - **Core product work.** This is where the differentiation lives, and where AI tools (Cursor, Claude Code, Copilot, Lovable for refactors) have made you faster than any junior contractor could ship. Outsourcing core product before you've productised your own AI workflow is the trap that kills budgets. - **Customer support, at least partially.** Your voice in support replies is a retention asset; offloading it entirely loses something. Maybe later, with a senior CS contractor; not on hire one. - **The honest founder voice in writing.** A contractor can draft posts in your voice, but the founder POV essays (the launch-day post, the "we hit a milestone" thread, the "why we made this decision" post) are uniquely yours. Keep those. The pattern: hire for the support activities around the product, not the product itself. The product is where you compound; the activities around it are where time leaks. ## Avoid the "hire a developer" trap The instinct to hire a developer first is strong and usually expensive. Three reasons it backfires. **You're already a developer (with AI).** Cursor, Claude Code, Copilot, and Lovable have made the median indie founder a genuinely productive developer. A junior contractor is unlikely to be meaningfully faster than you-plus-AI in your own codebase. You'd be paying $40 to $80 an hour for parity. **Onboarding a developer to a vibe-coded codebase is slow.** Your codebase has the quirks that come from AI-generated code: inconsistent patterns, files that grew organically, conventions you can't articulate. A contractor will spend two weeks finding their footing. You'll spend another two weeks code-reviewing their PRs. By the time they're productive, you've spent more than you saved. **The "I need help with the hard parts" framing is usually wrong.** The hard parts you can't do (heavy math, real-time infrastructure, advanced ML) need a senior consultant for a specific project, not a generalist contractor. The "hard parts" most founders actually mean (a refactor, a complex feature) are tractable with your current AI workflow if you sit with them for a focused day. If you're truly stuck on a specific technical problem, hire a senior specialist for a fixed-scope week or two, then end the engagement cleanly. Don't take on an ongoing developer contractor as your first hire. The version of this advice that's not universally true: if you're a non-technical founder with no AI workflow, a developer contractor may be the right first hire. But that's a different situation; this post is for vibe-coders who've built the thing themselves. ## How to write a one-week trial brief Whoever you hire, start with a paid one-week trial, not a multi-month contract. The trial brief is the most important document in the hire. What goes in a one-week trial brief: - **The outcome.** One paragraph. "By end of week, I want four published blog posts in this voice, on these four topics." Specific. Done-able. - **The voice / brand reference.** Two or three examples of work you'd point at as "do it like this." For a writer, two existing posts. For a designer, two screenshots or sites. - **The tools they'll use.** Notion for drafts, GitHub for code, Figma for designs, whatever your stack is. Pre-create the access. - **The cadence.** Daily async check-in or weekly sync? How they ask you questions when stuck? - **The success criteria.** What "good" looks like. For a writer: voice, structure, internal linking, accuracy. For a designer: hierarchy, fits the brand, no AI tells. - **The price and timeline.** Fixed amount for the trial week. After the week, you both decide whether to continue. The trial is the cheapest way to find out whether the working relationship is a fit. You'll know in five days. Most contractors who don't work out for an indie founder are not bad contractors; they're just a poor fit for your specific style and stage. Discover that with $800 on the line, not $8,000. If the trial goes well, formalise a short contract (one page is enough), set expectations for hours and deliverables, and proceed. If it doesn't, pay the trial fee, write a kind decline note, and try a different person. ## Capture the operating model in the project's spec This is the part most founders skip: the work you're outsourcing is part of how the product operates, and the operating model belongs alongside the product spec. A short paragraph in your project's spec or operations doc captures: - Which roles are outsourced and to whom - The deliverable cadence for each - Where their work lives (a content calendar Notion page, a Figma file, a shared Linear project) - What access they have and don't This sounds bureaucratic for one or two contractors, and it isn't. It means when you eventually hire a second contractor, the operating model is already written. It means when one contractor leaves, you can hand the brief to the next person without rebuilding the context. And it means your AI coding tool, reading the spec for product changes, has accurate context about who's doing what. [Draftlytic's project spec](/what-is-a-prd) is mostly about the product, but the constraints and external-services sections are also where the operating model lives once your project has one. Treat it as a living doc; update it the day you sign the first contractor. You can run an indie app solo for longer than the conventional wisdom suggests. Modern AI tools have made the solo footprint much wider than it used to be. But there's a quiet ceiling where you stop being more productive and start being a bottleneck on your own work, and the first hire is the move that breaks that ceiling. Not a developer. Usually a writer, an ads runner, or a VA. Always on a one-week trial first. Always with a written brief. Make the first hire small, specific, and easy to end, and the rest of the team build (if you choose to build one) gets dramatically easier from there.