How to Create a New App with AI Skills

Starting a new app is a race against two opposing failure modes. Move too slowly and carefully, and you spend six months perfecting an architecture for a product nobody wants. Move too fast and recklessly, and the prototype that got you your first hundred users becomes the tangled monolith that buries your next hundred features. Most “build a startup” advice tells you to pick a side. This guide refuses to. The whole point is to validate fast and keep your architectural options open — to earn the right to scale before you build for scale, but to never write code so carelessly that scaling means a rewrite.

The trick is sequencing. You do not need to be a great architect on day one; you need to make a small number of decisions early that are expensive to reverse later, and defer every decision that is cheap to change. Robert C. Martin calls this keeping options open. Eric Ries calls it minimizing the loop. John Ousterhout calls it strategic programming. They are describing the same discipline from three vantage points: spend your scarce early effort on the things that compound, and aggressively avoid waste everywhere else.

This guide walks you through that sequence with ten AI agent skills, each packaging a canonical book so your coding agent — Claude, Claude Code, Claude Cowork, Codex, Cursor, OpenClaw, Hermes Agent, or any other agentskills.io-compatible agent — applies the real framework instead of generic best-practice mush. You start by validating the riskiest assumption with the smallest possible build (Lean Startup) and de-risking the core flow in a week (Design Sprint). Then you establish boundaries that let you swap any detail later (Clean Architecture), model the business so the code reads like the domain (Domain-Driven Design), and write each function to be read (Clean Code). You apply the meta-disciplines that keep a codebase healthy (Pragmatic Programmer), size the system honestly before over-engineering it (System Design), make the interface feel native if you are on iOS (iOS HIG Design), ship on a cadence that fights feature creep (The 37signals Way), and treat complexity itself as the enemy at every step (Software Design).

Validate like you have no budget. Build like you will succeed.

You do not have to use all ten. A weekend prototype might lean on just the first two and the last one. A funded team building toward a real launch will want the whole stack. Read it in order, then pull the phases you need.

Phase 1: Validate the riskiest assumption before you build it

The most expensive mistake in software is building the wrong thing well. Before you open an editor, you need to know which of your beliefs would kill the business if it were false. The Lean Startup skill, drawn from Eric Ries’s book, turns that instinct into a method: identify your leap-of-faith assumptions, rank them by what would be fatal rather than what is easy to test, and design the minimum viable experiment that could falsify the riskiest one.

The key mental move is planning the Build-Measure-Learn loop backward. Do not start with “what should I build?” Start with “what do I need to learn?”, then “how will I know if I learned it?”, and only then “what is the smallest thing I can build to find out?” That reversal is what keeps an MVP genuinely minimal. An MVP is not a small version of the product — it is a learning vehicle, often embarrassingly crude. Dropbox validated demand with a video, not a sync engine. Zappos tested whether people would buy shoes online by photographing a local store’s inventory and buying retail when an order came in. Neither wrote the “real” product first.

Have your agent map the assumptions and pick the experiment type that tests the riskiest one with the least effort — a smoke test for demand, a concierge MVP for value, a Wizard of Oz for whether automation is even needed.

Once you have a candidate experiment, pressure-test whether it actually measures behavior rather than opinion. The skill is opinionated about this: surveys and “would you use this?” interviews produce vanity validation because people mispredict their own behavior. You want the validation ladder — signups are weak, a paid deposit is strong, active usage is strongest. Aim for level 4-5 before you build at scale.

A word on what this phase is not. It is not an excuse to skip engineering quality later, and it is not permission to ship something broken to real paying users under the banner of “MVP.” It is a way to make sure the thing you eventually build well is the thing worth building. When the experiment comes back with a clear signal — people commit, money changes hands, usage sticks — you have earned the right to build. If it comes back flat, you have a pivot-or-persevere decision, and you made it for the cost of a landing page instead of a codebase.

Phase 2: De-risk the core experience in five days

Validation tells you whether to build. A design sprint tells you what the core flow should be before you commit engineering time to it. The Design Sprint skill packages Jake Knapp’s five-day GV process: Map the problem on Monday, Sketch solutions individually on Tuesday, Decide on one on Wednesday, build a realistic Prototype on Thursday, and Test it with five real users on Friday. The output is not code — it is a high-fidelity facade and a pile of evidence about what confuses people, all gathered in a week.

This matters for a new app because the riskiest moment is usually the first ten minutes of a user’s experience, and that is exactly what a sprint targets. You are not testing whether your tech works; you are testing whether a stranger, handed your prototype with no explanation, understands what it is for and can complete the core task. The “five is the magic number” insight from the book is liberating: you do not need statistical significance, you need patterns, and patterns emerge after three to five people.

Use your agent as the sprint facilitator. It can run the structured exercises, generate How Might We reframes, and turn a winning concept into a click-through storyboard.

When you reach Friday, the discipline that separates a useful sprint from theater is in the interview. The skill enforces the five-act structure and, critically, the rule that you never explain the prototype — you let users struggle and watch where they get stuck. Have your agent write the interview script and a note-taking grid so you capture observations as ✓ / ✗ / ~ per participant and count patterns afterward.

Combine this phase with Phase 1 deliberately: the design sprint is the fastest way to produce a Wizard-of-Oz or single-feature MVP that you then put in front of users for a Lean Startup experiment. One de-risks the design, the other validates the demand. For the business-side framing around this same moment — positioning, pricing, go-to-market — the sibling guide on how to create a new business with AI skills picks up where this phase leaves off.

Phase 3: Draw boundaries that let you defer every other decision

Now you have validated demand and a tested core flow. This is the moment most teams blow it — either by reaching straight for a framework and letting it dictate the structure, or by skipping structure entirely “because it’s just an MVP.” The Clean Architecture skill, from Robert C. Martin’s book, gives you a single rule that resolves the tension: source code dependencies point inward, from frameworks toward use cases toward entities. Your business rules must not know whether data lives in Postgres or DynamoDB, or whether requests arrive over HTTP or a CLI.

The payoff for a new app is precisely option-keeping. When your business logic is isolated behind interfaces it defines, the database is a detail, the web framework is a detail, the payment provider is a detail — and details are plugins you can defer or swap without a rewrite. You can start with SQLite and a monolith, then move to managed Postgres and split services later, touching only the adapter layer. The skill’s diagnostic question is the one to keep asking: can you test your business rules with no database, no web server, and no framework running? If not, the dependencies are pointing the wrong way.

The mechanism is the Dependency Inversion Principle. Your use case defines an interface like InvoiceRepository; your infrastructure provides PostgresInvoiceRepository. The controller translates an HTTP request into a plain request object, calls the use case, and the use case returns a plain response object — never an ORM entity, never a framework type crossing the boundary. Have your agent design that layering for your actual feature.

Resist the urge to over-build this. The number of circles is not sacred — four is typical, but a small app might collapse adapters and frameworks into one layer. Draw boundaries at points of likely volatility (the database, third-party APIs, the delivery mechanism) and skip ceremony everywhere else. For a far deeper treatment of these decisions — data-intensive tradeoffs, resilience, when to split services — see the dedicated guide on designing the best architecture for a new app. For a new app, this skill is the high-leverage subset: get the Dependency Rule right and most other architecture mistakes become cheap to fix.

Phase 4: Model the domain so the code speaks the business

Architecture gives you the shape of the system; domain modeling gives it meaning. The Domain-Driven Design skill, from Eric Evans’s book, starts from a deceptively simple claim: the model is the code, and the code is the model. When the words your team uses in conversation are the exact words in the codebase — a Ubiquitous Language — a whole category of bugs disappears, because there is no translation layer between what the business means and what the code does.

For a new app this is cheaper to do now than ever again. You are establishing the vocabulary from scratch, so name things after domain concepts, not technical roles. An InvoiceDraft that knows how to finalize() is worlds better than a DataProcessor with a process() method, because a domain expert can read the former and tell you when it’s wrong. The skill treats naming difficulty as a design signal: if a concept is hard to name, your model is probably wrong.

The two structural ideas that matter most early are bounded contexts and aggregates. A bounded context is a boundary within which a word means exactly one thing — “Customer” in billing and “Customer” in support can be different models, and that is healthy, not a bug to unify. An aggregate is a cluster of objects with a single root that enforces consistency; keep them small and reference other aggregates by ID, not by object reference. Have your agent build the language and the boundaries first.

Then model the consistency boundaries. The most common new-app mistake here is the anemic domain model — objects that are just data bags while all the logic leaks into services. Push the behavior into the entities and value objects where it belongs.

Crucially, DDD and Clean Architecture are partners, not alternatives. The DDD repository interface lives in the domain layer; its implementation lives in infrastructure — which is exactly where Clean Architecture’s Dependency Rule wants it. Apply strategic design too: not every part of your app deserves deep modeling. Identify your core domain (the thing that is your competitive advantage) and invest your best thinking there; for generic subdomains like authentication, email, or payments, buy or use open source rather than over-engineering.

Phase 5: Write every function to be read, not just to run

You have a sound structure and a meaningful model. Now the code itself has to stay readable as it grows, because code is read far more than it is written — the ratio is well over ten to one. The Clean Code skill, also from Robert C. Martin, is the discipline that keeps your day-to-day code from rotting: intention-revealing names, small functions that do one thing, error handling kept separate from business logic, and tests treated as first-class code.

The temptation in a new app is to tell yourself you will clean it up later. You won’t — later never comes, and the broken windows accumulate. The skill’s core moves are concrete enough to apply on every commit. Functions should be small and operate at a single level of abstraction; a flag argument is a smell because it means the function does two things; commands and queries should be separate; and the best comment is usually a well-named extracted function. Point your agent at code as you write it and have it score and fix against these rules.

The other half of Clean Code is testing. The skill treats dirty tests as worse than no tests, because they become a liability that fights you on every change. Use it to generate tests that read like documentation — descriptive names like shouldRejectInvoiceWithNegativeTotal, one concept per test, and the F.I.R.S.T. properties (Fast, Independent, Repeatable, Self-validating, Timely). Because you followed Phase 3, your business logic is already isolated from infrastructure, so these tests are fast and need no database.

Phase 6: Apply the meta-disciplines that keep the codebase healthy

Clean Code operates at the function and class level. The Pragmatic Programmer skill, from Hunt and Thomas, operates one level up — the habits and meta-principles that determine whether a codebase stays easy to change over years. Four of its ideas are especially load-bearing for a new app.

First, tracer bullets. Instead of building layer by layer and integrating at the end, build one thin but real vertical slice through every layer — UI to use case to database and back — and keep it. It gives you end-to-end feedback immediately and a skeleton to flesh out, and it surfaces integration problems on day two instead of month two. This pairs perfectly with Phase 3: your first tracer bullet proves the Clean Architecture boundaries actually connect.

Second, DRY — but only for knowledge, not coincidental similarity. Two code blocks that look alike but encode different business rules are not duplication, and merging them couples concepts that should evolve independently. Third, orthogonality: changing the database should not break the UI, changing the auth provider should not touch billing. Fourth, reversibility: abstract third-party dependencies behind your own interfaces so you can swap Stripe for another processor, or one model provider for another, without rewriting business logic. Ask your agent to audit a planned design against these.

The Broken Window theory is the cultural glue here: the first hack is the most expensive because it gives permission for every subsequent one. If you cannot fix something now, board it up with a tracked ticket rather than leaving it as silent rot. For a brand-new codebase, establishing zero-tolerance for unexplained broken windows is one of the cheapest high-leverage habits you can adopt.

Phase 7: Size the system honestly — then stop

Here is where discipline cuts the other way. Having read about architecture and scaling, the temptation is to build for a million users you do not have. The System Design skill, from Alex Xu’s System Design Interview, is as useful for telling you what not to build as for telling you what to build. Its first principle is to start with requirements, not solutions — and its estimation tools let you prove, on the back of an envelope, that you do not need sharding yet.

Do the math before you provision anything. The skill gives you the numbers: queries per second is daily active users times actions per day divided by 86,400, with peak typically two-to-five times average; storage is records per day times record size times retention. For a new app with a few hundred users, that calculation almost always says “a single well-indexed database and a cache will carry you for a long time.” The common mistake the skill explicitly warns against is premature sharding — vertical scaling first, then read replicas, then cache aggressively, and shard last.

When you genuinely do hit a scaling decision — a read-heavy dashboard, a spiky background job like OCR on uploaded photos — the skill gives you the right building block for the right problem: a cache-aside layer for read-heavy paths, a message queue to absorb spikes and decouple the slow OCR work from the request path, a CDN for static assets. Reach for these when an estimate or a real bottleneck justifies them, not because a blog post said to.

Phase 8: Make it feel native if you are shipping to iOS

If your app has an iPhone client, “feels native” is not polish you add later — it is the reason iOS users trust an app at all. The iOS HIG Design skill encodes Apple’s Human Interface Guidelines: the three pillars of clarity, deference, and depth, plus the concrete rules that make the difference between an app that belongs on the platform and one that feels like a ported website.

The specifics are the value. Respect safe areas so nothing hides behind the Dynamic Island or home indicator; keep every touch target at least 44 by 44 points; use semantic colors like Color(.label) and Color(.systemBackground) so Dark Mode works automatically; use semantic text styles so Dynamic Type scales for accessibility; and use native navigation — tab bars for primary destinations, NavigationStack for drill-down, sheets for focused tasks — never an Android-style hamburger menu. Have your agent review your screens against these.

The skill also treats accessibility as a first-class concern rather than an afterthought: every interactive element needs an accessibility label, state needs an accessibility value, and you should be able to complete every task with VoiceOver alone. Building this in from the first screen is dramatically cheaper than retrofitting it before an enterprise accessibility review.

Phase 9: Ship on a cadence that fights feature creep

A new app’s greatest enemy after launch is the slow bloat of “just one more feature.” The The 37signals Way skill, distilled from Getting Real, Rework, and Shape Up, is the antidote: build less, fix time and flex scope, and ship on a predictable cadence. Its core principle — build half a product, not a half-assed product — is exactly the mindset that keeps a validated MVP from sprawling.

The central mechanic is shaping and betting. Before work reaches you or your team, it gets shaped: made rough enough to leave design freedom, solved enough to remove the big unknowns, and bounded by an appetite (“this is worth two weeks”) rather than an estimate (“how long will it take?”). Appetite is the crucial inversion — you fix the time and cut scope to fit, never the reverse. Then you bet shaped pitches into fixed cycles and let the circuit breaker kill anything not done at the deadline rather than letting it run forever. Have your agent shape your next feature.

The skill’s bias toward opinionated software is the other half of the discipline: every preference you offer is a decision you refused to make for the user. Pick sensible defaults, detect the timezone from the browser instead of asking, ship one good theme. Use the skill to challenge scope directly — its default answer to a feature request is a respectful “not now.”

Phase 10: Treat complexity as the enemy at every step

The final skill is less a phase than a lens you hold over all the others. The Software Design skill, from John Ousterhout’s A Philosophy of Software Design, names the real adversary: complexity, defined as anything about a system’s structure that makes it hard to understand and change. Its central design heuristic — deep modules — is the one to internalize. A deep module offers powerful functionality behind a simple interface; a shallow module imposes a complex interface for little benefit, adding complexity rather than hiding it.

This is the corrective to a subtle trap in the earlier phases. Clean Code’s “small functions” and DDD’s many building blocks can, applied without judgment, tip into classitis — a swarm of tiny shallow classes that each add an interface to learn without hiding meaningful complexity. Ousterhout’s measure cuts through it: judge a module by functionality provided divided by interface complexity imposed, not by line count. Sometimes merging three shallow classes into one deep one is the right move. Have your agent evaluate a design through this lens.

The skill’s other essential idea for a new app is strategic versus tactical programming. Tactical programming optimizes for getting this feature working now and accrues complexity with every shortcut; strategic programming invests a steady 10-to-20 percent extra effort in design, treating every change as a chance to improve structure. Ousterhout argues startups need this most, because early shortcuts compound into crippling debt exactly as the team and codebase grow. That is the throughline of this entire guide: validate cheaply, but once you commit to building, build strategically.

The only way to go fast is to go well — and the only way to go well is to know which decisions are worth the investment.

Your checklist

• Map your leap-of-faith assumptions and rank them by what would be fatal, not what’s easy to test (lean-startup)
• Design and run the smallest experiment that could falsify the riskiest assumption; aim for behavioral, level 4-5 validation
• Run a five-day design sprint on the core flow; test the prototype with five real users without explaining it (design-sprint)
• Establish the Dependency Rule: business logic testable with no database, framework, or web server (clean-architecture)
• Build a Ubiquitous Language and bounded contexts before writing feature code (domain-driven-design)
• Keep aggregates small, push behavior into entities, reference other aggregates by ID
• Write small, single-purpose, intention-revealing functions and clean tests on every commit (clean-code)
• Fire a tracer bullet — one real end-to-end slice — before building out features (pragmatic-programmer)
• Abstract third-party dependencies behind your own interfaces for reversibility
• Do a back-of-the-envelope capacity estimate and confirm what you do NOT need to scale yet (system-design)
• If on iOS, audit screens against the HIG: safe areas, 44pt targets, semantic colors, native navigation, accessibility (ios-hig-design)
• Shape each feature with an appetite, not an estimate; fix time and flex scope; default to “not now” (37signals-way)
• Favor deep modules over many shallow ones; spend 10-20% extra on strategic design (software-design-philosophy)

Common mistakes

Building the architecture before validating the idea. The most beautiful Clean Architecture is worthless if it serves a product nobody wants. Run Phase 1 first. Validation is cheap; a rewrite is not. The inverse is equally fatal — see the next item.

Treating “MVP” as a license to write garbage. Lean Startup says ship the smallest thing to learn, not the sloppiest. The validation experiments in Phase 1-2 are often not even code (landing pages, concierge, Wizard of Oz). Once an experiment greenlights real building, you are building the real thing — apply the engineering phases. Conflating “minimum” with “low quality” is how prototypes calcify into unmaintainable production systems.

Letting the framework dictate the architecture. If your business rules import your web framework or your ORM entities cross use-case boundaries, the framework has become your architecture and swapping it means a rewrite. Keep frameworks in the outermost ring as plugins (clean-architecture).

The anemic domain model. Objects that are pure data bags while all logic lives in fat service classes is the single most common DDD failure. It scatters business rules and duplicates them. Push behavior into the entities and value objects (domain-driven-design).

Classitis — over-applying “small.” Clean Code’s small functions and DDD’s many concepts can metastasize into dozens of shallow one-method classes that each add cognitive load without hiding complexity. Judge modules by depth (functionality per unit of interface), not by size (software-design-philosophy).

Premature scaling. Designing for a million users you don’t have wastes weeks and adds operational complexity that slows you down. Do the estimate; a single database plus a cache carries most apps far further than founders expect. Shard last, not first (system-design).

Skipping the tracer bullet. Building every layer in isolation and integrating at the end hides the integration bugs until they are expensive. One thin real slice through all layers, early, surfaces them when they are cheap (pragmatic-programmer).

Estimating instead of setting an appetite. Asking “how long will this take?” invites scope to grow until it fills the time. Asking “how much time is this problem worth?” fixes the budget and forces you to find the essential version (37signals-way).

Frequently asked questions

Do I really need ten skills to build one app?

No. The stack is a menu, not a mandate. A solo weekend prototype might use only lean-startup to scope it, clean-architecture to keep options open, and software-design-philosophy to stay simple. A funded team building toward a public launch benefits from the full sequence. The value is that each skill is the real framework from its source book, so your agent applies Ries or Evans or Ousterhout faithfully instead of improvising. Install the ones that match your stage and add others as the app grows.

What’s the right order — and can I run phases in parallel?

The order is deliberate: validate before you build (1-2), establish structure before you fill it in (3-4), then write and harden the code (5-6), size and polish (7-8), and ship sustainably (9), with complexity-awareness (10) running throughout. In practice the engineering phases overlap heavily — you will apply Clean Architecture, DDD, and Clean Code in the same pull request, with Pragmatic Programmer habits and the deep-module lens applied continuously. The one ordering rule that is non-negotiable: do not skip validation to get to the fun part of building.

How is this different from the architecture deep-dive guide?

This guide is the full lifecycle of creating an app — from “is this idea worth building?” through shipping and keeping the codebase healthy. The companion guide on designing the best architecture for a new app zooms into Phase 3 and 7 specifically, going much deeper on boundaries, data-intensive tradeoffs, and resilience patterns. Start here for the end-to-end picture; go there when the architecture decisions themselves are the hard part. For the commercial side — positioning, pricing, acquisition — see how to create a new business with AI skills.

Won’t all this discipline slow down my prototype?

The framing that quality and speed are opposites is exactly what these skills reject. Ousterhout’s data is that strategically designed systems become faster to work in within months, not years — the investment pays back fast because every future change is cheaper. The trick is matching effort to stage: in validation, your “build” might be a landing page, so there’s almost no code to keep clean. Once you’re building the real product, the 10-20% strategic overhead is what keeps you fast as the codebase grows past the point where a tactical mess would have ground you to a halt.

My agent doesn’t seem to apply the skill — what am I doing wrong?

Two things usually fix it. First, name the skill explicitly in your prompt — “Use the clean-architecture skill to …” — so the agent loads it rather than relying on general knowledge. Second, give it a concrete artifact to work on: a real class, a real feature, a pasted file. The sample prompts above are deliberately specific (“my InvoiceService class”, “the photo OCR step”) because skills produce sharper output when anchored to your actual code instead of a hypothetical.

Get started

Install the foundational skills and point your agent at the first decision that matters — what to build and whether it’s worth building:

npx skills add wondelai/skills/lean-startup --global
npx skills add wondelai/skills/clean-architecture --global
npx skills add wondelai/skills/domain-driven-design --global

Add the rest of the stack as you move through the phases, or grab the whole library at once with npx skills add wondelai/skills --all --global. Then open your agent and start with the riskiest assumption — validate it cheaply, and you’ll have earned the right to build it well.

When the validated idea turns out to be more about the commercial model than the code, continue with how to create a new business with AI skills. When the architecture itself becomes the hard problem, go deep with how to design the best possible architecture for a new app.