Are most SaaS founders wasting time building?
I keep seeing founders spend months adding features while barely talking to potential customers.
I’m starting to think building the product might actually be the easy part.
Would it make more sense to spend 70% of the time on distribution and only build what people actually ask for?
Or is that just another startup Twitter opinion?
Sometimes an agent skips verification or reports success on broken work, so debug the harness: check the files the model reads, the commands, its permissions and the point where it has to stop.
Write a contract first
Before anything runs, I write down the deliverable, the constraints, what the model must not touch and the acceptance criteria. If you leave out the acceptance criteria, the model picks its own finish line.
Keep state and a map in files
I keep a short root file that lists where the docs, schemas and source code live, so the model opens only the file the current step needs. Decisions, preferences and open bugs go in CLAUDE.md or .cursorrules, so a fresh session picks up where the last one stopped.
Run tests instead of asking the model
If you ask "are you sure?", the model agrees with itself. pytest, vitest or a schema checker returns an exit code. The loop moves forward only on a pass, and I cap it at four attempts.
Encode important rules twice
I put each important rule in the prompt and also add a gate that blocks the action. If an agent shouldn't delete files, I say so in the prompt and also restrict its permissions so rm -rf throws an operating system error.
file
I save this as HARNESS.md in the project root:
# Project Operating Contract
## Operating Boundaries
- Allowed scope: Modify only files explicitly assigned in the current task
- Forbidden actions: Never delete existing tests, never add unverified dependencies
## Project Map
- /src: Application source code
- /tests: Validation test suites
- /docs/decisions.md: Durable log of accepted architectural choices
## Verification Protocol
Before marking any task complete, run these checks in order:
1. Run local linter: `npm run lint`
2. Run test suite: `npm test`
3. Verify output format matches the requested schema
## Failure Escalation
If a test fails twice on the same error:
- Stop autonomous editing
- Print the exact error log
- State the proposed fix and wait for user confirmation
Two passes in plain chat
In plain chat, I draft in one turn and critique in another.
Draft the technical specification for [Feature X].
Follow the constraints listed in HARNESS.md.
Do not evaluate your own output yet.
Output the raw draft and state all assumptions made.
Review the draft above as a skeptical senior reviewer.
Check against these specific failure points:
1. Are edge cases handled when input arrays are empty?
2. Does the logic introduce extra dependencies?
3. Does the solution violate any constraint from HARNESS.md?
List every failure point found.
Then output the revised version fixing those gaps.
I gave my agent a full feature task with requirements, it had almost like 20 steps in 1 run. It got to around step 17 and failed. Also it became complicated for me as well to figure out which one step had messed things up, and the only way to retry from the top.
So I stopped doing one big run. Long tasks now go through a pipeline with checkpoints between stages:
Research
↓
Checkpoint
↓
Plan
↓
Checkpoint
↓
Task 1 → verify
↓
Task 2 → verify
↓
Task 3 → verify
↓
Checkpoint
↓
Task 4 ...
A checkpoint is a snapshot of where things are: what's done, what got decided, what failed, what's left, and anything the next run needs to know. If the agent dies halfway, I load the last one and keep going. I don't have to scroll back through the chat trying to piece it together.
The verify steps turned out to be the bigger deal for me. Before I added them, I was checkpointing broken code and the next run built on top of it.
The state lives in a plain file outside the agent. Mine is usually `PROJECT_STATE.md`:
Current goal: ...
Completed: ...
Known issues: ...
Decisions: ...
Next task: ...
The agent reads it at the start of every run. It only needs to know where the project is right now.
Right now I'm doing it after every task that touches more than one file.
A common way to make an agent "smarter" is to give it more tools.
Like: Search. Code execution.APIs.Databases.Browsers.
But every additional tool also gives the agent another possible path to take. That can mean: unnecessary tool calls, slower execution, higher costs, more opportunities for failure
I have made this mistake before while building agents for my workflow. Understand one thing: the important part of an agent isn't giving it another capability. It's giving it a reason to stop, skip a tool, or ask for help instead.
I understand giving an agent context for a single task, but I'm more curious about what happens when the same agent keeps running over a long period of time.
Do you store everything in a database, summarize old interactions, or only keep specific information?
I'm wondering what actually works once the context starts getting huge.
I've been going through Claude Code's features and there are a few that I think are easy to miss when you're mostly using it for basic coding tasks.
/plan is the one I started paying more attention to for bigger changes. Instead of immediately asking Claude to edit everything, I can have it look through the project and work out what needs to change first.
For larger features, I find that much easier to reason about.
/compact is useful once a session gets really long. Rather than throwing away the whole conversation and starting again, I can compact the context and keep working with the important information.
I can use /permissions when I want more control over what Claude is allowed to do. This is useful when I'm working in a project where I don't want to manually approve every harmless action but also don't want to give it unrestricted access.
Git worktrees make running multiple tasks much cleaner for me.
git worktree add ../feature-auth feature-auth
I can keep a separate working directory for a feature without constantly switching my main working tree between branches.
**The -**p flag is useful when I want Claude to behave more like a command-line step.
claude -p "Review this diff for obvious bugs"
I can pipe information into Claude and use its output as part of another workflow instead of having to interact with it manually every time.
Hooks are another feature I think becomes more useful as a project gets bigger. I can use them to automatically run things like formatting, validation, or other checks around Claude's actions.
I've also found that keeping instructions scoped makes more sense than putting everything into one huge file. Project-wide rules can stay in the main instructions, while rules specific to tests, APIs, or another part of the project can stay closer to the code they apply to.
For me, the bigger takeaway is that Claude Code becomes a lot more useful once I stop treating it like just a chatbot that writes code.
The context, permissions, workflow, and verification around the model matter just as much as the prompt itself.
I've been looking into agentic workflows lately, and I noticed that a lot of the systems that look complicated are actually built around a few pretty simple patterns.
These are the ones I keep seeing:
Sequential is basically the straightforward one. I have one step finish before the next one starts.
Research → Summarize → Write → Review
I've found this makes sense when each step depends on the result of the previous one.
Routing is where I let the system decide what should handle a request. Instead of sending everything to the same agent, I can have a router classify it first.
User request
↓
Router
↙ ↓ ↘
Code Search Support
I can see this being useful when one application needs to deal with several completely different types of requests.
Parallel workflows are useful when I don't need tasks to wait for each other. For example, if I'm researching something, I can have separate agents look at different sources at the same time and combine the results afterward.
Evaluator → Optimizer is the pattern I find particularly interesting. I have one agent produce something, another check it against specific criteria, and then the first one gets another pass if something needs fixing.
The important part for me is defining what the evaluator should actually check. “Make it better” doesn't give it much to work with.
Human-in-the-loop is pretty much what it sounds like. I can let the agent prepare an action while keeping the final approval with me.
Agent → Prepare → Human approval → Execute
I'd use this whenever the action has consequences that I don't want an agent deciding on its own.
Fan-out/fan-in is basically splitting one task into smaller tasks and bringing the results back together.
→ Task A →
Big task → → Task B → → Combine → Task C →
What I've realized is that I don't necessarily need a complicated multi-agent setup just because I'm building an agent.
A lot of the architecture comes down to deciding what needs to happen in order, what can happen at the same time, and where I want a human or another model to check the result.
The more capable these workflows get, the more interesting the boundaries become. There are tasks where handing everything over makes sense, but there are probably also things where having a human make the final call is actually faster than debugging an agent's decision afterwards.
For people running agents regularly, where do you draw that line? And has that boundary changed as you've gotten more comfortable with agents?
I'm curious about the practical side of running agents for longer tasks. My agents can get halfway through something, make a wrong assumption, and then just keep looping
Do you have some kind of timeout/retry limit or human checkpoint built into your workflow? Or do you just let it run and check on it periodically?
Not a demo that worked once. Something you've had running long enough that you stopped thinking about it.
Could be checking something, summarising information, handling a repetitive coding task, watching for changes, whatever.
I'm especially interested in the stuff that isn't impressive in a demo but saves you 20–30 minutes every day.
What did you automate, and how much maintenance does it actually need?