01
We start small.
When uncertainty is high, an Architecture Review, Audit Readiness Sprint, or focused inception phase reduces risk before a larger commitment. If sustained execution follows, the work moves into a named two-person principal pod.
How we work - The operating model behind every Stackpad engagement.
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
Five operating principles.
02
We work inside your repo.
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
We bias toward written artifacts.
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
We default to the smallest reversible decision.
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
We staff for the work, not the calendar.
Stackpad’s founders approve client fit and the proposed team. The designated principal delivery lead joins before scope is finalized, and the approved team is the team that performs the work.
What an engagement looks like
From first call to handoff.
Week 0
Scope conversation
A 30–60 minute call to map the real decision and choose the smallest useful starting point. Stackpad’s founders approve fit and the proposed team. Before scope is finalized, you meet the principal who would lead day-to-day delivery.
Week 1
Access and orientation
The delivery lead gets into your repo, cloud environment, communication channels, and operating rhythm. We read more than we write. By the end of week 1, the pod has a working model of how the system actually behaves—not just how the docs say it works.
Weeks 2–N
The work
For a sprint: gap analysis, remediation, and evidence packaging. For an Architecture Review: mapping, written assessment, and a prioritized risk list. For a principal pod: two named principal engineers own a defined outcome, with one clear day-to-day delivery lead.
Throughout
Communication
The delivery lead handles day-to-day work and communication. You receive a written weekly status covering progress, decisions, risks, and next steps. Stackpad leadership reviews account health, and material scope, security, performance, or staffing issues escalate immediately.
End of engagement
Closeout, renewal, or expansion
We review what shipped, what remains open, continuity needs, and the next business decision. Handoff, renewal, and expansion are deliberate choices—not automatic extensions—and Stackpad’s founders remain the commercial decision point.
What we promise upfront
Four things we won’t do.
- We won’t take engagements we can’t actually staff. If the timeline doesn’t work, we’ll say so on the first call.
- We won’t write a slide deck instead of code. If the deliverable should be code, the deliverable is code.
- We charge by the engagement, not the slide. A 4-week sprint produces 4 weeks of remediated systems and packaged evidence — not a closing presentation.
- We won’t pretend to know something we don’t. If the problem is outside our experience, we’ll tell you and suggest who you should actually call.
Not sure your software can carry what’s next?
In 30 minutes we’ll ask the questions a good technical lead would ask and tell you plainly what we’d look at first. No pitch deck.