DEV Community: Stephen Dale

Your first SaaS hire probably shouldn't be an engineer

Stephen Dale — Fri, 26 Jun 2026 09:14:39 +0000

Cross-posted from noflattery.com/decide — where I ran this exact question through a council of four different frontier models and let them argue it out.

You're a solo founder at ~$8K MRR. You have runway for exactly one full-time hire. Which role unlocks the most growth?

(A) a second engineer to ship features faster
(B) a marketer to build a real acquisition channel
(C) a customer-success / support hire to cut churn and free your time
(D) a salesperson to chase larger deals

The intuitive answer for most technical founders is A — more shipping velocity. The case below is for C, and it's stronger than it looks. (With one caveat that can flip the whole thing — stick around for it.)

TL;DR: At ~$8K MRR solo, hire customer success first if churn is real or support is eating your week. If voluntary churn is under ~3% and support is light, hire a marketer instead. Engineer and sales come later.

The case for customer success first

1. Churn quietly eats growth before features can add it. At $8K MRR, 5% monthly churn is ~$400/month bleeding out before you grow an inch. Across bootstrapped SaaS in the $5–15K MRR band, the strongest predictor of reaching $50K isn't feature velocity or channel — it's net revenue retention above 90%. That's a customer-success function, not an engineering one.

2. You are the bottleneck, and support is eating you. As a solo founder you're doing product, sales, billing, and support. If support takes ~15 hours a week, that's nearly 40% of your capacity — and it's the cheapest thing to hand off. A CS hire costs less than a senior engineer or an experienced salesperson, and it buys back the hours (and the headspace) you need to think strategically again.

3. It's a research department in disguise. A CS hire generates the highest volume of qualitative signal: why people leave, what they actually use, what they'd pay more for. An engineer builds what you think users want. CS tells you what they actually need — which means the engineer you hire next builds the right thing instead of the wrong thing faster.

4. It's the only hire that makes every later hire better. Lower churn stabilizes runway → you can afford the next hire without sweating. Customer insight → aims your future engineer. Case studies and referrals → arm your future marketer or salesperson. Every other first hire operates in a silo. CS creates a feedback loop.

5. It's the role you can actually manage well right now. A marketer needs strategy and positioning you may not have yet. A salesperson needs a repeatable playbook. An engineer needs a backlog. A CS hire needs your ear and a process doc — and a bad CS hire costs ~2 months to recover from, versus ~6 for a bad engineering hire. Lowest downside, fastest correction.

The caveat that flips it

All of the above rests on one unverified assumption: that churn is your binding constraint.

If your voluntary monthly churn is under ~3% and support isn't consuming your week, you don't have a retention problem — you have an acquisition problem. Hiring CS then is a tourniquet on a paper cut while you bleed out from the top of the funnel. In that case, hire the marketer.

So before you post any job description:

Calculate your voluntary monthly churn. Above ~3–5% with growth stalling → retention is the constraint → customer success.
Count your weekly support hours. If it's eating your week → CS.
Low churn + low support, healthy signups but flat top-of-funnel? → acquisition is the constraint → marketer.

The decision genuinely flips on that one number. Measure it first.

Why I framed it this way

I built NoFlattery so I could run decisions through a council of AI agents that argue instead of agreeing with you — each agent on a different model. All four independently voted C, for different reasons: the numbers, the systems leverage, the founder's bandwidth, and the compounding feedback loop. The full debate, per-model votes, and verdict for this question are here:

👉 Who should a bootstrapped SaaS founder hire first? (full council debate)

What was your actual first hire — and would you make the same call again?

How I Built an Adversarial AI Council in React (and Why It Argues With You)

Stephen Dale — Fri, 19 Jun 2026 06:20:43 +0000

A local-first, single-file SPA where multiple agents debate your decision and hand you a verdict.

The problem: every AI I asked just agreed with me

I almost named this project wrong.

I'd picked a name that sounded powerful. I asked ChatGPT, and it loved it. I asked Claude, and it nodded along. Nobody warned me about the trademark conflict, the wrong search intent, or the SEO fight I'd pick with the BBC.

That was the moment I realized the problem wasn't the name. It was the feedback loop. Most AI assistants are tuned to please, so they hide your blind spots instead of showing them. When you need to make a consequential decision, "sounds great" is the most expensive answer you can get.

So I built the opposite: a council of AI agents that disagree on purpose.

What NoFlattery does

NoFlattery puts 2–4 agents in a room, gives them different reasoning biases, and makes them debate your decision. The output isn't another chat transcript. It's a Decision Record: a clear verdict, the reasoning behind it, the main risk, what would change the call, and a next step.

Use it for product decisions, pricing, tech stack, hiring, or any call where one perspective isn't enough.

Key product choices:

Local-first: your chats and API keys stay in your browser.
BYOK: bring your own OpenAI, Anthropic, OpenRouter, or Ollama key.
One-time price: no subscription, no account, no data harvesting.

The stack

The whole app is a single-file SPA built with:

React 19 + TypeScript
Zustand for state
Dexie over IndexedDB for local-first storage
Vite + vite-plugin-singlefile for a single index.html deploy
An OpenAI-compatible provider runtime so users can plug in their own keys

Why single-file? Because the deploy becomes dead simple. One HTML file. No server for the data. No build orchestration. I can ship the app to Cloudflare Pages and forget about it.

The turn engine: deterministic, not magical

The heart of NoFlattery is a turn-based multi-agent engine. One user message triggers one round. Each agent speaks in order, with a defined bias. There are no hidden selector models deciding who talks next. No silent fallbacks that break identity contracts.

The flow looks like this:

User asks a question.
Each agent generates a response based on its role and the conversation so far.
Agents can @mention each other to force a direct response.
At the end of the round, the user can reply, ask for a summary, or start a new decision.

Discussion modes are prompt injections, not separate state machines. Adversarial mode makes agents challenge harder. Audit mode makes them look for flaws. Vote mode forces a clear verdict. This keeps the runtime small and predictable.

Local-first by default

Every conversation, every API key, every preference lives in IndexedDB via Dexie. Nothing leaves the browser unless you choose to call a provider with your own key.

This isn't a compromise. It's a feature. For a tool about honest decisions, the privacy model should match the message: your data is yours.

The only server touch is license validation for Pro. Even that is just a key plus a device hash. No chat history. No prompts. No telemetry.

Lessons learned

1. Users don't want another chatbot.

They want a decision they can defend. The transcript matters less than the verdict. That's why the Decision Record is the first-class output, not the chat.

2. Single-file deploy removes a lot of headache.

No Docker. No DB migrations. No "works on my machine." I run npm run build and get one index.html. The infrastructure complexity drops to near zero.

3. Local-first is a trust shortcut.

Especially for early users who don't know you. "Your data stays in your browser" is easier to believe than "we promise not to look."

4. Determinism matters more than cleverness.

I tried smarter routing. Hidden selectors. Model-based orchestration. Every time, the system became harder to debug and less trustworthy. One round, one order, one identity per agent. That's the constraint that makes the product feel reliable.

Try it

If you have a decision you'd run through a council:

https://noflattery.com

Drop the decision in the comments. I'm curious what a room of disagreeing agents would say about it.