Cam IncollFieldwalker was built from first commit to launch-ready in nine weeks by a solo founder using AI-assisted development. This is a look at what that actually involved — what worked, what didn't, and why the process matters more than the technology.
On February 6th, 2026, I created a project folder with 23 files and 448 lines of scaffolding. No features. No database. No endpoints. Just the shape of what the project would become.
Nine weeks later, Fieldwalker is a full permaculture design application. AI-powered feature detection. Automatic contour generation from multiple elevation sources. A design editor with 12 specialised tools, keyboard shortcuts, full undo/redo. Subscription billing. Security hardening. An admin panel. A CI/CD pipeline. Deployed to production.
I built this as one person, using AI as my implementation partner. Here's what that actually looked like.
What AI-assisted development means in practice
Let me be specific about what "AI-assisted" means here, because the term gets thrown around loosely.
I didn't type "build me a permaculture design app" and wait for code to appear. That's not how this works. AI-assisted development, the way I practise it, is a structured collaboration. I make the product decisions. I write the specifications. I define the architecture. I design the user experience. Then I write a detailed session brief and hand it to an AI coding agent to implement.
The AI writes the code. I review the output. I test. I provide feedback. We iterate.
The critical insight is that the quality of the output depends almost entirely on the quality of the input. Vague briefs produce vague code. Tight, specific, well-structured briefs produce tight, working implementations. The AI is a force multiplier for clear thinking, not a replacement for it.
The session brief pattern
The workflow that emerged over nine weeks looks like this:
Before each session, I write a self-contained brief. It includes a context block telling the AI which files to read first, any blocking bugs to fix, a numbered list of tasks in priority order, explicit scope rules (what to do and what not to do), and a reporting template for the end of the session.
The key word is self-contained. The AI has no memory between sessions. Every brief needs to carry all the context required for the work. If I assume the AI remembers something from last time, the session fails. If I'm precise about what exists, what needs to change, and what the acceptance criteria look like, the session succeeds.
This constraint — no assumed context — turned out to be one of the best things about the workflow. It forced me to be clear. Every session started with documented assumptions, documented scope, documented boundaries. There was no ambiguity to drift into.
What the timeline actually looked like
The first real features landed three days after scaffolding. By February 9th, the app had authentication, project management, image upload, and a canvas editor. By February 18th — day twelve — AI detection was working end-to-end. Three days after that, the detection pipeline had expanded to include specialist models for trees, buildings, and roads.
The pace was fast, but it wasn't reckless. Each session had clear scope. Each deliverable was tested before moving on. Documentation was maintained as the project grew, not as an afterthought.
The really intense sprint came in early March. In a single week, I ran sessions that covered UX polish, canvas interaction consistency, the symbol library, the layer panel, security headers, database optimisation, memory profiling, the admin panel, monitoring, and CI/CD. Nine sessions. Tracks one through three complete.
By mid-March, the design tools had expanded from 8 to 14 symbol types, with scale-aware sizing, GeoJSON boundary import, and a GPS coordinate editor. By late March, the editor got a complete toolbar redesign, undo/redo, and keyboard shortcuts. Stripe billing went live. A full security audit was completed and closed.
What worked
Documentation as a first-class concern. Every session ended with documentation updates. Progress logs, architecture notes, spec revisions. This sounds boring, but it's what made the next session possible. Without documentation, each session would have started with archaeology instead of building.
Tight scope per session. Each brief had explicit "DO NOT" rules. Don't implement the feature that's scheduled for next session. Don't refactor the thing that works. Don't add the nice-to-have. The scope discipline is what made nine weeks possible. Without it, every session would have ballooned.
Deferring deliberately. A lot of features were explicitly deferred. Design Groups — deferred to V2. Full Konva migration — deferred. Plant database — deferred. Snapping system — deferred. The product is better for what it doesn't include, because every feature that shipped got full attention.
Fixing bugs first. Every session brief started with blocking bugs from the previous session. Fix what's broken before building what's new. This kept the codebase healthy and prevented technical debt from compounding.
What didn't work
Long sessions lose focus. When a session ran too long without checkpoints, the AI would start drifting from the scope. It might fix a bug in a way that introduced a new pattern inconsistent with the rest of the codebase. Or it might start "improving" things that weren't in the brief. Shorter sessions with tighter scope produced better results.
Assumed context. Early on, I sometimes wrote briefs that assumed the AI remembered the previous session. It doesn't. Every time I made that assumption, the output was wrong in subtle ways — using the old API structure, or missing a pattern that was established two sessions ago. The fix was straightforward: make every brief self-contained.
Under-specifying acceptance criteria. When I wrote "implement the panel" without specifying what "done" looked like, I got an implementation that technically worked but didn't match what I had in mind. When I wrote "the panel should show X, Y, Z in this order, with this behaviour on click, and this empty state," I got exactly that.
The human part
I want to be clear about what the AI doesn't do.
It doesn't make product decisions. It doesn't know that permaculture designers need an asymmetric swale symbol or that dense vegetation should render as a canopy blob. It doesn't know that contour accuracy matters more than contour aesthetics. It doesn't know that the target user is a PDC graduate trying to produce their first professional design.
All of that — the product judgement, the domain expertise, the user empathy — is human. The AI is spectacularly good at translating clear specifications into working code. It's not good at deciding what to build, or why, or for whom.
This is why the combination works. I've spent years in product design. I run a farm. I've been through the permaculture design process myself, and I know where the workflow breaks down. That understanding shaped every decision about what Fieldwalker does and how it works. The AI made it possible to implement those decisions in nine weeks instead of nine months.
What this means
I'm not writing this to say "AI is amazing" or "anyone can build a SaaS now." Neither of those is quite right.
What I am saying is that if you have genuine domain expertise — if you deeply understand a problem space and the people who live in it — AI-assisted development dramatically reduces the distance between understanding the problem and shipping a solution. The bottleneck moves from implementation to specification. The constraint is no longer "can I code this?" but "can I describe this clearly enough?"
For me, that shift meant I could build the tool I've needed for years, in the timeframe of weeks rather than months, without hiring a team, without raising money, without compromising on quality.
Nine weeks. 23 files to a full product. And the design process continues.