Paddock20 — How We Build
How your software
actually gets built.
If you've hired someone to build software before, you know the sinking feeling: the project vanishes into a black box, weeks go by, and what comes back isn't what you pictured — but the invoice is bigger than you pictured, too.
We built our process to kill that feeling. One build philosophy — Digest. Develop. Deliver. — running through five client-facing stages: Align → Meet → Coach → Lead → Reflect.
Stage 01
Align
Get the brief right before anything moves.
What it means
Align is the stage where the problem gets named. Not the symptom — the constraint itself. Most failed software projects fail here, before a line of code is written, because the brief was wrong or missing entirely. Align is about building shared language between the person who owns the outcome and the person who will build for it. Without this, everything downstream is expensive guesswork.
What it looks like in a working engagement
A Free Fit Call is the entry point. The first session is nothing but listening — what's the actual hold-up, who uses this day to day, what's already been tried, what does success look like in 90 days. The output is a one-page brief: problem statement, scope boundary, success criteria, and a recommendation on whether to build, configure, or do nothing. That document is the engagement's north star.
Signals you're here
- No written brief or requirements exist yet
- Multiple people have different ideas of what's being built
- Previous attempts stalled before they started
- The team is cautious or skeptical about new tech
Stage 02
Meet
The plan gets built. The tools get chosen.
What it means
Meet is where the brief becomes a build plan. The problem is named, but the approach is still open. This stage is about deciding what gets built, in what order, with what tools — and locking in the architecture before the first sprint. The cost of choosing wrong here is high, but recoverable. The cost of skipping it entirely is usually a full rebuild six months later.
What it looks like in a working engagement
We map the full scope into a phased build plan — what ships in Phase 1, what comes after, what gets descoped. Tool selection happens here: which AI model, which stack, which integrations, what gets custom-built versus configured. A working prototype or wireframe is the deliverable — something concrete enough to pressure-test the plan before committing to it.
Signals you're here
- Brief exists but no build plan
- One person is driving this, team hasn't fully bought in
- Tools have been discussed but nothing selected
- Timelines are known but the roadmap isn't defined
Stage 03
Coach
The build is moving. Keep it on track.
What it means
Coach is the most common stage where builds go sideways. The team is moving, but the original brief is drifting. Features get added, scope expands, the original problem statement gets blurry. Coach is about active course correction — not adding more, but keeping the build aligned to what it was supposed to do. The job here is to remove friction, not add capability.
What it looks like in a working engagement
Ongoing architect oversight during an active build. Weekly syncs to pressure-test what shipped against the brief. We review PRs, flag scope creep before it compounds, and make architectural calls when the build hits forks in the road. If something is drifting, it gets named and corrected at the weekly — not after six weeks of drift.
Signals you're here
- Build started but keeps drifting from original spec
- More tools keep getting added mid-build
- The team has the skills but keeps making wrong decisions
- Shipped features aren't matching what was discussed
Stage 04
Lead
The build is live. Ship it clean.
What it means
Lead is where the hardest builds live. The problem is named, the plan is solid, the team is capable — and it's still not shipping. This stage is defined by specific, identifiable blockers: an integration that won't behave, a performance ceiling that needs architectural surgery, a deadline with hard pressure behind it. Lead isn't about strategy anymore. It's about execution under pressure.
What it looks like in a working engagement
Direct hands-on build work. Inside the codebase, not advising from outside it. Blockers get worked as they surface — pairing sessions, direct code contributions, architecture decisions made with context instead of in a meeting. The engagement at this stage is intensive and short: identify the blocker, resolve it, and get the build back to momentum.
Signals you're here
- Build is active but hitting the same walls repeatedly
- Specific integrations or features are blocking everything else
- Deadline pressure is real and timeline is compressing
- Previous attempts at this specific problem haven't held up
Stage 05
Reflect
It's live. Keep it running. Make it better.
What it means
Reflect is the post-launch stage. The software is live and in production, but the work isn't done, it's shifted. The job now is observability: is it performing under production load, are users using it the way it was designed, where are the next constraints forming? Reflect is also where institutional knowledge gets captured so the system doesn't become dependent on one person.
What it looks like in a working engagement
A production review engagement. A structured audit of what's live: performance benchmarks, error rates, user behavior, architectural debt, and the gap between what was built and what's being used. The output is a prioritized improvement roadmap and a decision on whether Phase 2 is a new feature set, a performance pass, or an architecture consolidation.
Signals you're here
- Software is live but no one is monitoring it systematically
- Performance issues are appearing under production load
- Users are using it differently than designed
- No clear owner for what happens when it breaks
