What we do for you

Each stage produces something the next one needs. Your goal shapes the path, the path shapes the stack, content and media fill the block diagram, and the block diagram turns into epics and stories we can estimate. Skip a stage and the gap shows up later as rework, which is the most expensive kind of work there is.

Every later decision traces back to this one. Before anyone picks a database or writes a story, we agree with you, in plain words, what the project must achieve and how you'll know it worked.

The answers go into a one-page project brief. It becomes the reference point for every scope question that comes up later.

A new build starts from a blank page and your brief. A conversion starts from a system people already use every day, and that system becomes the source of truth. The two paths share the later stages but start very differently.

The stack has three layers, and each answers a different question. The database decides how your data is stored and kept safe. The backend decides the business rules and who can do what. The frontend decides what people see and touch.

How we choose

• Team skills. A stack the team knows ships faster than a better one it doesn't.
• Typed, compiled code. Type checks and builds catch mistakes in seconds, which keeps AI-written code honest.
• Data shape. Records with relationships belong in a relational database.
• Hosting and cost. We match where you already run things.
• Longevity. Tools with a large community and a long support window.
• Start simple. One deployable app split into clear modules beats early microservices.

Late content is one of the most common reasons a launch slips. We start collecting in week one, give every piece an owner and a due date, and treat it like any other dependency on the plan.

Example content inventory rows

Images, video, and drawings need the same tracking as text, plus two more checks: every file needs the right format and size for the web, and proof that you have the right to use it.

media/
├── _source/          # originals, never served
├── home/
│   ├── home-hero-crew-at-sunrise-1920.webp
│   └── home-hero-crew-at-sunrise-960.webp
├── products/
│   └── product-a-overview.mp4
├── brand/
│   ├── logo-full-color.svg
│   └── logo-white.svg
└── rights.csv          # file, source, license, expiry

We draw two pictures. The sitemap shows what pages exist and how people move between them. The system diagram shows which parts run where and how they talk. Together they turn a brief into something we can count, and every block becomes an epic or a story in the next stage.

The block diagram becomes a backlog in Jira or a similar tool. Epics come from the big blocks, stories come from the pages and features inside them, and sub-tasks are the steps a developer or an AI agent takes to finish a story.

Example story card

With AI agents doing much of the building, one hour figure per story hides where the time really goes. We estimate two kinds of effort on every story, and track waiting separately.

Sizing guide

These numbers are a starting point. Dev time shrinks more slowly than AI time, because review and testing take about as long whether a person or an agent wrote the code. Small stories often carry as much Dev time as AI time.

Example estimate

Example estimate for the project in the brief: 43 AI hours and 37 Dev hours across 5 epics. Not a quote.

We go through this list together as the project moves. Try it: your ticks stay in this browser only.