Part 4 — Beyond the MVP · 16 min read

When to get tech advice

The signals that mean stop and call someone, how to brief them, and how to tell a good one from a bad one.

At some point you'll hit something that a non-technical founder with an AI genuinely cannot resolve. Not because you're not clever enough — because the thing needs judgement that comes from having seen it go wrong before, and no amount of prompting substitutes for that.

Knowing when you've hit one of those is a skill in itself. Get it wrong in one direction and you burn a week on something a competent engineer would have diagnosed in twenty minutes. Get it wrong in the other and you pay someone to do work you could have done yourself.

The triage list

Stop now and call someone	Get help this week	Plan for it
Real customer data has been lost, corrupted, or exposed	You've been stuck more than a day with no progress	You're about to take payments
You suspect a breach, or found a leaked credential in use	You're about to store sensitive information — health, financial, anything about children	A second person is about to start editing the code
Users can see each other's data	Production is down and you can't work out why	A business customer has sent a security questionnaire
Anything involving money moving incorrectly	You're making a decision that's expensive to reverse — data model, auth, hosting	Investors are about to do technical diligence
You've received a legal or regulatory letter	Something works intermittently and you can't reproduce it	You're integrating with a partner's system

The four shapes of help

Shape	What it is	Good for	Roughly
A second opinion	An hour on a call, screen shared	"Am I about to do something stupid?" Decisions, stuck bugs, sanity checks.	A few hundred dollars, or a favour
A review	Someone reads your code and infrastructure and writes up what they find	Before launch, before payments, before a customer's diligence	One to three days of someone's time
A contractor for one piece	They build the specific thing that's beyond you	Payments, a tricky integration, a migration, performance work	Scoped per project
Fractional / ongoing	A senior person with you part-time, on a retainer	Initial setup done right, then regular checkpoints as you build	A monthly retainer scaled to days used

Australian senior contract rates are commonly quoted somewhere in the range of A$800–1,600 a day, with specialists above that and agencies higher again. Treat that as orientation only — rates move, and scope matters more than the day rate. Get two or three actual quotes.

What to prepare before you talk to anyone

This is where most of the value is won or lost. A good engineer with good context can help you in an hour. The same engineer with no context spends that hour working out what you've built.

Repository access — read access to your private repo, not a zip file.
Your CLAUDE.md and docs/ folder. Your spec documents, your handover notes, your debts list. This is a better briefing than most companies manage.
The specific problem, written down. What you expected, what happened, the actual error text, what you've already tried.
What "done" looks like to you, concretely.
Your constraints — budget, timeline, and that you're non-technical and will need things explained.
Access, ready to grant — hosting, database, error tracking. Read-only first.

Say plainly how it was built

"I built this myself with AI tools. I'm not a developer. I understand the shape of it but not the details." That sentence saves everyone an awkward twenty minutes, and a good contractor will respond well to it — it tells them exactly how to talk to you.

You are also handing them something better than they usually get: a mainstream stack, a real commit history, written specs, and a founder who knows what they don't know. That's a stronger starting position than plenty of funded companies.

Telling a good one from a bad one

Good signs	Red flags
Asks questions before quoting	Quotes immediately, without understanding the problem
Explains things in a way you follow, without condescension	Uses jargon to close down questions
Willing to say "I don't know, I'd need to look"	Certain about everything
Suggests the smallest thing that would help first	Opens with "this all needs rewriting"
Tells you what you could keep doing yourself	Positions themselves as permanently necessary
Leaves you with notes and a clearer picture	Fixes it silently and you learn nothing
Comfortable with AI-assisted code — engages with what's there	Contemptuous about how it was built

What not to outsource

Pay for expertise. Don't pay away your understanding.

Knowing what your product does and why. Never someone else's job.
The decision about what to build next. That's product, and it's yours.
Your relationship with your users. Nobody can do your customer conversations for you.
Understanding the shape of your own system. You don't need to read every line. You do need to know what happens when someone signs up.

Ask whoever helps you to explain what they did and why. A good one will expect that. If someone would rather you didn't understand your own product, that tells you what you need to know.

Or talk to me

I'm Will Foster. I wrote this guide using AI, with my own experience as the input.

I build AI engineering platforms: currently the first engineering hire at Procuracon, principal advisor at OrchLab, and previously an engineering manager at Amazon (Prime Video checkout funnel, Fire TV) and Snapchat. I've also built and shipped a consumer app, DriveSaver, end to end through my own agentic framework — which is roughly the journey this guide describes.

Two ways I can help. If you're a founder who wants the things on this page — a second opinion, a review before launch, or a fractional engineer at the checkpoints — get in touch and we'll work out whether you need me. And if you get to the point of having an engineering team, OrchLab's work is exactly that: hands-on training run against your own repositories, plus a hardened agent sandbox and codebase-semantics layer installed into your repos so it outlives the engagement.

Start a conversation → wfoster.dev

I'd rather tell you that you don't need help yet than sell you something you don't.

Triage: do I actually need a human for this?

I'm a non-technical founder and I've been stuck on something. Help me decide honestly whether to keep going or get help.

The problem: [describe]
How long I've been on it: [time]
What I've tried: [list]
What I understand about the cause: [be honest, including "nothing"]

Tell me:
1. Is this something I can realistically solve with you, or does it need someone with production experience? Be honest rather than encouraging.
2. If it's solvable: what's the single next diagnostic step, and what would each possible result tell me?
3. If it needs a human: what kind of help — an hour of advice, a review, or a contractor for a piece of work?
4. What should I have ready before that conversation so I don't waste their time or my money?
5. What's the risk if I keep grinding on this alone for another day?

Consider the cost of my time, not just whether it's theoretically possible.

Assemble a context pack for an advisor

I'm bringing in an experienced engineer to help me. Prepare everything they'll need so the first hour is productive.

Create docs/context-pack.md containing:
1. What this product does and who it's for, in a paragraph
2. The stack, and how it's deployed
3. A map of the codebase: what lives where, and which files matter most
4. How data flows through the app for the main user journey
5. The honest state of things: what's solid, what's held together with tape, what I know is wrong
6. Known issues and technical debts, with the trigger conditions
7. What I can do myself, and what I definitely can't
8. What I want from them specifically, and what's out of scope

Be honest about weaknesses rather than presenting this favourably — they'll find out anyway, and it wastes the engagement if they find out slowly.

Evaluate the advice I've been given

Someone has reviewed my project and told me [paste their assessment or recommendation].

Help me evaluate it as a non-technical founder who can't judge this directly:

1. Which parts are objectively true, based on the actual code?
2. Which parts are reasonable judgement calls where a different engineer might disagree?
3. Which parts look like personal preference presented as necessity?
4. If they've recommended a rewrite or a major change: what specifically can't be fixed incrementally, and does that hold up?
5. What questions should I go back and ask them?
6. If I did nothing they suggested, what would actually happen and when?

I'm not looking to dismiss their advice — I want to understand it well enough to make my own decision.

Write your escalation plan

Help me write a short escalation plan — the things that, if they happen, mean I stop working alone and call someone immediately.

Based on my specific app ([describe], storing [what data], with [payments / no payments]), give me:
1. The five situations where I should stop touching the code immediately, and why in each case continuing makes things worse
2. The warning signs that precede each one
3. Who I'd need in each case — a developer, a security specialist, a lawyer
4. What I should do in the first ten minutes of each, before help arrives
5. What I should NOT do, especially the instinctive reactions that make things worse

Keep it to one page. Save it to docs/escalation.md so it exists before I need it.

Exercise 1 Write your escalation plan now

Run the escalation prompt and save the result. Then read it and check you'd actually follow it — particularly the "don't touch anything" instructions, which are the hardest to obey when you're panicking.

You'll know it worked when it's committed to your repo. The value is entirely in having decided calmly, in advance, what "too serious to handle alone" means.

Exercise 2 Assemble your context pack

Run the context pack prompt and produce docs/context-pack.md. Read it as if you were a stranger. Would you understand this product in ten minutes?

You'll know it worked when you could send it to someone tomorrow and they'd arrive at a call already useful. Keep it current — it's also the fastest way to onboard your first hire.

Exercise 3 Book one hour, before you need it

Find someone — a friend who's an engineer, a contractor, a fractional advisor — and buy an hour of their time to review what you've built so far. Not because something's broken. Before anything is.

You'll know it worked when you've had the conversation and written down what came out of it. Founders overwhelmingly do this too late, when something is already on fire and the options are worse and more expensive.