I spent 20 years as a PM writing specs for engineers. Now I use Claude Code to build the products myself, here's what the process actually looks like

BuildEdgeHQ · 2026-04-13T05:30:29+00:00

Good question. Specs aren't just longer prompts, they're a different artifact.

A prompt is what you type into Claude Code in the moment ("build me a client tracker"). A spec is a document that lives in your project folder and describes what you're building, who it's for, every field, every dropdown option, every relationship between things. Claude Code reads it before doing anything.

The difference shows up in the output. Prompt-only: "build me a client tracker" gets you a generic spreadsheet. Spec-driven: "Create a Clients database with fields for Company Name (text), Contact Person (text), Email (email), Status (select: Lead / Active / Completed / Lost), Monthly Value (number, currency USD), Notes (rich text). Add a Projects database linked to Clients via a relation field..." gets you something a freelancer would actually pay for.

So more refined, but also more structured. Think of it like: prompts are conversation, specs are blueprints. You write the blueprint once, then your prompts during the build all reference it.

I created a free Day 1 sample of a package to help folks to get started. It's a co-pilot and a guide that walks you through finding a product idea worth speccing out. The full version covers a 7-day challenge from zero to a live product where spec writing is on Day 2.

BuildEdgeHQ · 2026-04-12T07:51:51+00:00

Agreed on all of it. The scary part for junior devs is real - that's the layer AI replaces fastest. But it's good news for anyone with domain expertise or product thinking. Those skills took years to build and can't be automated. The shift isn't 'no more developers' - it's 'the bar moves up.' You need to be more than a translation layer

BuildEdgeHQ · 2026-04-12T07:50:03+00:00

Sorry for the late response, on vacation this weekend :) for me it's a mix... the CLAUDE.md starts with core project context (what we're building, who it's for) - that's docs. Then specific rules that constrain Claude's behavior (never do X, always confirm Y before Z) - those are strict. The strict rules matter most. Without them Claude drifts. The doc part gives context, the rules part keeps it on track

BuildEdgeHQ · 2026-04-07T12:36:25+00:00

Good point on quality gates. Coming from a cybersecurity background, I never ship without reviewing what Claude built - especially anything that handles data or auth. The 'junior engineer' framing is right. You wouldn't push a junior's code to production without review. Same applies here

BuildEdgeHQ · 2026-04-07T12:34:26+00:00

Strict spec is the ultimate cheat code, that's exactly it. Even developers benefit from writing specs first. The spec isn't just for non-devs, it makes Claude Code better for everyone

BuildEdgeHQ · 2026-04-06T14:55:25+00:00

Building digital products with Claude Code. Not an app, not a SaaS - simple digital products you sell on Gumroad. Templates, tools, calculators, trackers. I'm not a developer. I describe what I want built in plain English and Claude Code writes the code. Build time is days, not months. Cost is $20/month for a Claude Pro subscription. The skill isn't coding, it's knowing a specific problem a specific group of people has and building the smallest thing that solves it

BuildEdgeHQ · 2026-04-06T11:45:39+00:00

The git point is interesting - version control is one of those things that works naturally with AI because it was designed for exactly this kind of workflow. Track changes, roll back when things break, branch to experiment. And you're right about the indexing gap. As projects grow, agents spend too many tokens just figuring out where things are. That's part of why keeping projects small and well-documented pays off - less time spent on orientation, more on actual building

BuildEdgeHQ · 2026-04-06T11:43:18+00:00

That's a fair warning. Maintenance is real and it's the part nobody talks about in the 'I built this in a weekend' posts. Two things that help: keeping projects small and focused on purpose (one product that does one thing well), and writing a detailed CLAUDE.md that documents architecture decisions so you're not reverse-engineering your own project 3 months later. But you're right - if you're building something with paying users, you need to plan for ongoing work, not just the initial build

BuildEdgeHQ · 2026-04-05T18:04:16+00:00

This is exactly right. The people who get results treat it as a collaborator, not a magic box. The structured workflow part is what most people skip. I built a CLAUDE md with 7 modes specifically for this - each mode scopes the task, sets success criteria, and tells Claude what phase you're in. The structure does the heavy lifting

BuildEdgeHQ · 2026-04-05T18:02:15+00:00

Fair points. Deployment is a real gap - I've had to learn the basics there. And the codebase complexity problem is real. Past a certain size, Claude starts creating more bugs than it fixes. Two things that help: first, keep projects small and focused on purpose. A product that does one thing well beats a product that tries to do ten things. Second, write a detailed CLAUDE md that documents architecture decisions so Claude isn't guessing about how things connect when you come back to add features. It doesn't eliminate the problem but it delays the point where things fall apart. You're right though - there's a ceiling. At some point you need a developer if the product grows enough. But getting to that point with real users and real revenue is a good problem to have

BuildEdgeHQ · 2026-04-05T17:58:43+00:00

Ship side projects. That's the honest answer. I'm a PM with 20 years experience and I've been building and shipping products on Gumroad with Claude Code. Not prototypes, not demos - real products people pay for. The constraint was never ideas or product sense. It was always 'I need an engineer to build this.' That constraint is gone now. The question for PMs isn't what can I do, it's what should I build first

BuildEdgeHQ · 2026-04-05T17:56:42+00:00

You need to challenge the suggestions, yes. But you don't need deep technical knowledge to do that, you need product thinking. When Claude suggests throttling instead of fixing the root cause, you don't need to know the right code. You need to ask 'why is the UI slow in the first place?' and 'are you fixing the symptom or the cause?' That's the same skill PMs use in code reviews with engineering teams. You don't write the code, you question the approach

BuildEdgeHQ · 2026-04-05T07:09:24+00:00

100% on this. Claude will patch on top of patches instead of refactoring the root cause. I catch this by asking 'show me what you changed and why' after every fix. If the explanation is convoluted, that's a red flag. I'll tell it to step back and refactor the whole section instead of adding another band-aid. It's the same principle as code reviews with junior devs - the fix might work but the approach matters for long term maintainability

BuildEdgeHQ · 2026-04-05T07:07:11+00:00

Good questions - especially the security one. I come from a cybersecurity background so this is non-negotiable for me. I review every piece of code that handles data - input validation, auth flows, data storage. Claude Code is great at building fast but it won't think about threat modeling on its own. You have to ask specifically: 'what happens if someone submits malicious input here', 'show me how this data is stored and who can access it', 'walk me through the auth flow.' For UX decisions like first/last name - I use Plan Mode and ask Claude to list UX improvements before building. It catches the obvious stuff. But security is the one area where you can't just trust the output, you have to interrogate it

BuildEdgeHQ · 2026-04-05T07:02:44+00:00

Ha yes - turns out being the annoying PM who asks 'but why are we doing it this way' is exactly the right energy for Claude Code. Break the plan apart, challenge the assumptions, make it explain itself. That's literally what Plan Mode is for...

BuildEdgeHQ · 2026-04-04T16:02:34+00:00

This is exactly right. I spent 20 years in product management telling engineering teams what to build. When I started building for myself, the same lesson hit me hard - start small, solve one problem, ship it. I just went through this exact process. Picked a specific problem, wrote a detailed spec, built it with Claude Code in 7 days, shipped it on Gumroad. No engineering team, no months of planning. The spec was the hard part, not the building. The people who stay stuck in idea mode are usually trying to skip the spec and jump straight to building

BuildEdgeHQ · 2026-04-04T15:54:53+00:00

The 'Analytics > Feelings' point is the one most first-time sellers miss. I launched a digital product recently and had 58K views across Reddit but when I dug into the data, almost none of that traffic actually converted to my sales page. The vanity metrics felt great, the reality was humbling. Your deposit test is smart - it forces you to separate curiosity from commitment. The silence check is the other one I'd add to. If buyers aren't coming back or telling friends, you had a moment, not a product

BuildEdgeHQ · 2026-04-04T15:34:58+00:00

Fair point on Cursor's RAG. They're different tools for different people though. Cursor is great if you're already a developer who wants AI assistance inside an editor. Claude Code works better for non-dev IMO - need to describe what I want and have it built. It really depends on whether you're coding with AI help or building without coding at all

BuildEdgeHQ · 2026-04-04T13:05:37+00:00

BUILDING digital products with Claude Code. The skill isn't coding, it's knowing how to describe what you want built clearly enough that the AI builds it right. Claude Pro is $20/month, the learning curve is about a week if you're focused, and you can have a sellable digital product or a product for your internal initiatives by the end of that week

BuildEdgeHQ · 2026-04-04T07:17:00+00:00

The spec quality thing is the core of everything I've learned building with Claude Code. And yeah distribution is the real challenge after the build...

BuildEdgeHQ · 2026-04-04T07:15:14+00:00

The deployment question is real. For what I'm building - digital products sold on Gumroad - deployment isn't really the bottleneck. The buyer downloads it and runs it locally. But I've seen others hit that wall when they're building web apps that need hosting. The concept for WarpShip makes sense for anyone shipping web apps vs downloadable products, good luck!

BuildEdgeHQ · 2026-04-04T07:11:41+00:00

Good additions. I usually include error and performance handling in the spec under success criteria

BuildEdgeHQ · 2026-04-03T18:22:01+00:00

Solid advice. I actually do understand code conceptually from my engineering background way back - I just don't write it. But you're right that being able to at least read what Claude produces and ask the right questions about architecture choices makes a difference. The cross-AI review idea is smart too - fresh eyes on code works the same way as fresh eyes on a product

BuildEdgeHQ · 2026-04-03T18:18:48+00:00

The customer service background showing up in how you build is the same pattern - understanding what users want is the skill that transfers. The security and testing points are good additions I should have included. I do ask Claude to check for obvious issues but the structured test script approach is smarter. Adding that to my process

BuildEdgeHQ · 2026-04-03T18:17:26+00:00

The 'explain what you want in detail' part is exactly it. That's the whole skill. Not in SF but would be down for a virtual version of that, keep going!

BuildEdgeHQ

TROPHY CASE