Build Stuff: Shipping Software Without a Software Team

I am a strategist. I understand ideas. I know what needs to be built, why it matters, who it's for and what good looks like when it's done. I've spent thirty years turning business problems into briefs. But until now I've never had the skills to design or code, to make those ideas any more real than a written document. A deck. A spec. Words on a page that someone else turned into something you could actually click or swipe.
That was just how it was for people like me. You thought. You briefed. You waited. You reviewed what came back and tried to explain, again, that this wasn't quite what you meant. The gap between the idea in your head and the thing on the screen was always someone else's job to close.

Build Stuff is the third category in the Task Framework. It's the one where the ground is moving fastest. And it's the one that people from my side of the building, the strategy side, the commercial side, the Powerpoint side (well, Keynote in my case) tend to underestimate the most. Because building software was the exclusive preserve of designers and coders and engineers. If you couldn't write code, you couldn't build. Full stop.

That full stop has been erased.

What "Build Stuff" actually means

Build Stuff is any task where you produce working software. Code, applications, tools, integrations, websites, dashboards, calculators, automations that need real logic rather than just wiring together APIs. If it runs and does something when someone uses it, that's building.

Worth being honest about what this doesn't mean. AI isn't turning everyone into a software engineer. Designing robust, scalable, secure systems at the scale and security that businesses need is still a proper discipline that takes years to develop. What AI has done is carved off a huge slice of work that used to require that discipline and made it accessible to people who have ideas but no engineering background. People like me.

There are three layers to this that are worth committing to memory.

Prototypes. Fast, disposable, built to test an idea. You'd actually never ship them to customers but they validate whether something is worth building properly at all. What used to take an engineer a week now takes an hour. This is the layer where most people will spend most of their time. It's also the layer that quietly changes how organisations work, because it means the person with the idea can now show it rather than just describe it.

Internal tools. Small team, known users, trust assumed. The stakes are lower because the blast radius is smaller. If it breaks, you fix it or do the task manually for a day. Just this week we encountered an issue with a client's Learning Management System. So we built our own LMS in an afternoon, in three languages, to host an AI training programme. What would have stopped a project in its tracks for weeks became a mild inconvenience.

Production software. Customer-facing, at scale, regulated, reliable under load, properly secured. AI helps here too but the engineer doesn't disappear. They move up the stack into reviewing, integrating and battle hardening the software. In general, leave stuff like this to the experts.

Why the prototype layer matters more than you think

For most people reading this, prototypes are the game changer. They're where you'll spend your time, and they're worth far more than they look.

A prototype is an idea made tangible. It's the thing that closes the gap between what you meant and what someone else understood. I've lived on the wrong side of that gap for years, which means the first iteration of what gets built is usually technically what you asked for but not quite what you meant. You go round again. Everyone's polite about it but the budget is already half gone and no one's happy.

A good working prototype is the best brief your agency, consultancy or internal dev team will ever have received. It eliminates the thing that kills software projects more reliably than anything else: ambiguity. Any briefing document, no matter how well crafted, hands the builder a set of sentences to interpret. A prototype hands them something they can play with and experience before they write a line of code. That's what prototypes do. They don't replace the builders. They give the builders something real to build from, and they let the people with the ideas stop translating and start showing.

You know that app idea you keep describing at dinner. Go build a prototype this weekend. It'll take less time than explaining it again.

The tools to use right now

Snapshot of April 2026. Categories matter more than names because the names will change.

Agentic coding assistants. Claude Code is our daily driver at Jointly. Codex from OpenAI is the equivalent but it's not great yet. You describe what you want, it creates your codebase, the UI, a basic back end, proposes changes, runs tests.

AI-first Integrated Development Environments (IDEs). Cursor and Windsurf wrap an editor around the same capabilities. GitHub Copilot has evolved from autocomplete into something much closer to a pair programmer.

No-code app builders. Lovable, Bolt, Replit Agent and v0 by Vercel. You describe the app in plain English, it produces a working version, you iterate by chatting. These are where non-technical people should start. The barrier to entry is whether you can hold a conversation.
Design to code. Figma Make and v0 read a design file and turn it into running code. One for graphic designers or the design inclined.
Backends and hosting. Supabase has become the default database for prototypes and internal tools. Vercel and Netlify deploy your fresh app in a couple of clicks.

How to prompt for building

Start with the problem, not the solution. "Build me a form" is a bad prompt. Give the AI the user's actual need and let it suggest the shape for the end product.

Describe the user journey. Walk through who uses it, in what order, to do what. You know this already if you've ever written a brief. The difference is the reader can now act on it immediately.

Be honest about scale and stakes. AI will build a prototype or a production tool happily, but it'll make different choices if you tell it which.
Iterate by running it. Treat the software as something you poke at, not something you read. Click every button. Try to break it. The feedback you give after using it is ten times more useful than the feedback you give after looking at it.

Know when to throw it away. A new conversation with a clearer brief beats ten rounds of patching and fixing. Prototypes are cheap. Your time isn't.

Where Build Stuff goes wrong

First, people build things that already exist. There's a SaaS for that. Ask whether the market has solved this before you solve it yourself.

Second, people ship prototypes by accident. The demo works, excitement builds, suddenly forty people rely on it. Prototypes are for learning and briefing. If it proves valuable, bring in an engineer to build it properly.
Third, people underestimate security. If anything touches personal data, financial data or anything regulated, don't ship it until someone qualified has looked at it.

Fourth, and this is the one I care about most, people don't build at all. They know the tools exist. They've seen the demos. But they stay in their inbox, stay in their PowerPoint world, keep writing briefs and waiting for someone else to make the thing. The excuse used to be that building required skills you didn't have. That excuse is gone. If you can describe what you want clearly enough to brief a human, you can describe it clearly enough to build a prototype. The people who get this will move faster, communicate better and waste less of everyone's time. The people who don't will still be waiting for the dev queue to clear.

Becoming fluent in Build Stuff

Fluency here is less about learning to code and more about learning to think like someone who ships. You distinguish between prototype, tool and product. You use the prototype as a thinking and briefing instrument, not as the finished article. You know when to bring in an engineer and you give that engineer the best starting point they've ever had.

Software used to be something you requested, a line item on a roadmap six months away. Now it's something you draft, like a document or a deck, you produce a version, you share it, you improve it. Building has joined the list of things that anyone with a clear idea and a bit of persistence can do.

I spent thirty years on the briefing side of the wall. The wall's still there for the hard stuff, the production-grade, scalable, secure stuff. But for everything between "I have an idea" and "here's what I mean," the wall is gone. And honestly, standing on this side of it, I'm not sure why anyone would choose to go back.

Next time: Make Sense of Stuff. How AI turns the dashboard you never open into a decision you can actually make.