Consultancies fail when the operating model is invisible. You sign a contract, you get a Slack channel, and then you spend three weeks figuring out what they actually do day-to-day — usually by the time you’ve already paid for those three weeks.
This page is the operating model, written down. How engagements start. What week one looks like. How we communicate. What we deliver. How engagements end. Read it before you talk to us — if anything here doesn’t fit, we’re probably not the right partner and you’ll save us both a call.
Principles
01
Every engagement begins with a defined scope — a 2-week review, a 4-week sprint, or a starter retainer. Long-term partnerships compound from the first useful thing we ship. They don’t start with a six-figure commitment from a cold call.
02
Embedded means embedded. We use your tools, your standups, your code review process. We don’t run a parallel project on our own infrastructure and hand you a deck at the end.
03
Diagrams, risk lists, decision logs, runbooks. Things that survive the engagement and that the next person can pick up. Slack threads aren’t deliverables.
04
Most teams over-engineer the things they haven’t proven yet and under-engineer the things that will get audited. We try to do the opposite, and we explain the call when we make it.
05
Stackpad leadership leads every engagement. Senior engineers join as scope requires. The team grows with demand. You won’t get handed from a senior partner to a junior implementer — the people you meet are the people doing the work.
What an engagement looks like
Week 0
A 30–60 minute call. We figure out what you actually need (which is often different from what you asked for), tell you which engagement shape fits, and tell you if we’re not the right partner. The bar to start is a deadline or a decision — not a project plan.
Week 1
We get into your repo, your AWS account, your Slack, your standups. We read more than we write. By the end of week 1, we have a working mental model of how the system actually behaves under load — not just how the docs say it works.
Weeks 2–N
For a sprint engagement: gap analysis, remediation, evidence packaging. For an Architecture Review: mapping, written assessment, prioritized risk list. For a build: shipping code alongside your team. For a retainer: showing up to the decisions, the design reviews, and the incidents that matter.
Throughout
Asynchronous by default — written artifacts in your repo or wiki. Synchronous when it helps — design reviews, weekly standups if you want us there, on-call pairing during incidents. You decide the cadence; we adapt to it.
End of engagement
A written closeout — what we shipped, what we didn’t, the open risks, and the things your team should keep watching. For retainers, this happens at the end of each quarter so you always have an off-ramp. We’d rather you keep us because you want to than because the system would fall over without us.
What we promise upfront
Have a product to build?
A first product, a new platform, a complex integration, a launch date, or an audit in the distance — the more specific you can be about the build, the more useful our first reply will be.
