Platform Engineering Consulting: What to Expect From a 90-Day Engagement
A plain account of how a pilot-first engagement works, what a good 90 days delivers, what it needs from you, and how to tell a real one from a slide deck.
Executive brief
- A well-run 90-day platform engineering consulting engagement should leave you with one golden path running in production with real teams on it, working pipelines and infrastructure code in your own repositories, a measured before and after, a named ownership model, and a roadmap your own engineers can execute. If you get only a strategy document, the engagement failed.
- It starts with a scoped pilot, and you pay for the pilot only if it completes successfully against criteria agreed in writing beforehand. The 90-day plan is signed after the pilot succeeds, never before.
- This is hands-on implementation, not advice: the engineers build the CI/CD pipelines, infrastructure modules, service templates, guardrails and observability in your environment, with tools chosen to fit your stack.
- The typical rhythm: two weeks measuring your actual delivery data, two weeks choosing the thinnest useful slice, a month building with the launch team, three weeks widening to more teams, and ten days on handover.
- You bring three things: a sponsor with authority over at least two teams, two named internal engineers who will inherit the platform, and a launch team that feels the pain today.
- Ninety days builds the first part of an internal developer platform and proves it works. It doesn't build the whole thing, fix org-chart disputes, or migrate your entire estate.
- Judge any firm by adoption and lead time, not by features shipped. Ask who will write code in week five, and ask to meet them before you sign.
What a 90-day platform engineering engagement actually is
Platform engineering consulting is a fixed-length engagement where outside engineers work next to your team to build the first usable piece of an internal developer platform, and to leave you able to keep building it without them. The word doing the work in that sentence is "usable." A platform no product team chooses to adopt is a cost center with a nice logo.
Ninety days is long enough to get something into production and short enough that the sponsor still remembers why they signed. It's about the time it takes to go from "we think developers are slowed down" to "here's the evidence, here's the fix, and three teams are running on it." Shorter than that and you've bought an assessment. Much longer and scope tends to swell into a platform rewrite that nobody agreed to.
An internal developer platform, for the record, is the self-service layer between your engineers and your infrastructure: templates, pipelines, environments, guardrails, and the documentation that makes them findable. The CNCF's platforms white paper lays out the typical capabilities and how to think of the platform as a product for internal users. It's worth reading before your first vendor call.
Can an engineer on a product team go from an empty repository to a running service in a non-production environment this week, without filing a ticket or asking anyone for access? If finding out takes a meeting, that's your starting baseline, and it's the number the engagement should move.
How it starts: a pilot you pay for only if it succeeds
Before any 90-day commitment, we run a scoped pilot. One real workflow, one real team, working in your actual tooling. The success criteria are written down and agreed before anyone writes a line of code. A typical criterion might be a new service going from empty repository to running in a non-production environment through the new path with no tickets, with time to first deployment measured before and after.
You pay for the pilot only if it completes successfully against those criteria. If it doesn't, you don't pay for it.
The 90-day plan gets signed after the pilot succeeds, not before. By then you've watched the engineers work, you've seen the result in your own environment, and the bigger commitment rests on measured evidence instead of a proposal. It also removes an awkward failure mode: a firm sells you 90 days, learns your estate on your time, and discovers in week three that its approach doesn't fit.
Ask every firm on your shortlist what you owe if the pilot doesn't meet its success criteria. If the answer is "it depends," or the criteria aren't in writing before work starts, you're carrying a risk that belongs to them.
Before the pilot: what you need to bring
Consultants get blamed for a lot of engagements that were doomed at kickoff. Three things predict whether 90 days will land, and none of them is the consultant's skill.
- A sponsor with real authority over at least two delivery teams. A director who can't make a team change how it deploys will watch the platform go unused.
- Two internal engineers, named, with time carved out of their sprints. They inherit everything on day 91. If you can't spare them, you're buying a consultant-run platform that decays once the last invoice is paid.
- One launch team that's actually feeling the pain. The pilot runs with this team, and it's the first team on the new path once the 90 days begin.
Choosing the launch team deserves more thought than it usually gets. Skip your strongest team, since they've already built their own workarounds and won't give you honest signal. Skip the one in crisis too, because it will eat the whole engagement. A middle team with a deadline and a grudge about deployments is the best launch team you'll find.
Hand over read access early: source repositories, CI history, cloud accounts, and the incident log for the last two quarters. Slow access in week one is the most common reason a 90-day plan turns into a 120-day one.
Can you write down, right now, the names of the two engineers who will own the platform on day 91? If the honest answer is "we'll sort that out later," hold the start date until you can.
The 90-day playbook, phase by phase
Once the pilot has succeeded and the 90-day plan is signed, this is the shape the engagement takes. Whatever the pilot measured feeds straight into the baseline. Dates slip by a few days here and there, but the order rarely changes.
- 1
Days 1 to 15: Measure what's actually happening
Interview eight to twelve engineers across at least four teams. Pull lead time, deployment frequency, change failure rate and time to restore from your own Git history, CI logs and incident records. Then pick one service and trace it by hand from commit to production, writing down every wait, ticket and manual approval. The output is a baseline built from your data and a ranked list of friction, not a maturity score from a questionnaire.
- 2
Days 16 to 30: Choose the thinnest useful slice
Pick the one workflow where friction is highest and the fix is repeatable across teams. Common candidates are new-service scaffolding, the deployment pipeline, or environment provisioning. Write a one-page spec for the first golden path, decide what to build and what to adopt (Backstage, an existing CI platform, Terraform modules you already own), and agree success metrics with the sponsor. Day 30 is a real checkpoint: the sponsor can say go, change direction, or stop.
- 3
Days 31 to 60: Build it with the launch team, not for them
Consultants and the two named internal engineers pair with the launch team on templates, pipeline stages, infrastructure modules, guardrails written as policy as code, and documentation. The consultants write real code and configuration in your repositories, using your cloud accounts and CI system, so everything built is yours. The test at day 60 is blunt: the launch team ships a real service, one that matters to the business, on the new path. A demo doesn't count.
- 4
Days 61 to 80: Widen to two or three more teams
Onboarding new teams is where the platform gets its real feedback. Watch where people get stuck, because that's your product backlog. Fix the top issues as they appear, and re-measure the day 1 to 15 numbers so the before and after comparison is honest.
- 5
Days 81 to 90: Hand over and set the next two quarters
Write runbooks, define who owns the platform and who's on call for it, set up an intake process for requests from product teams, and produce a roadmap ranked by measured pain with rough sizing. The engagement closes with a readout of before and after numbers, and with your internal engineers already running the thing without the consultants in the room.
On measurement: the four delivery metrics from the DORA research program (lead time for changes, deployment frequency, change failure rate, time to restore) are a sensible default, because they're hard to game and your tooling already produces most of the raw data. If your teams have adopted AI coding assistants, track stability next to throughput. Our AI delivery baseline shows which numbers to pull from Git history.
If you want to run the first phase yourself before talking to anyone, TuskerGauge helps find delivery gaps, and Tusker90Pro turns findings into a 90-day improvement roadmap.
At day 45, has anyone on the launch team used the new path for work they'd otherwise have done the old way? If not, don't wait for day 60 to raise it. Adoption stalls early and quietly.
Hands-on implementation: what actually gets built
A pile of recommendations isn't what you're paying for. At every stage the engineers build in your environment, and what they build is committed to your repositories and runs in your accounts. The table shows the usual areas. The technologies are examples, because tools get chosen to fit the stack you already run.
| Area | What gets implemented | Example technologies |
|---|---|---|
| CI/CD pipelines | Build, test, security scanning and promotion across environments, as reusable pipeline templates | GitHub Actions, GitLab CI, Jenkins, Argo CD |
| Infrastructure as code | Reusable modules for networks, clusters, databases and per-team environments | Terraform or OpenTofu, Pulumi, Helm |
| Developer self-service | Service templates, a software catalog, and documentation people can find | Backstage, or a lighter portal if that fits |
| Guardrails | Policy as code, secrets handling, safe defaults for access | OPA, Kyverno |
| Supply chain | SBOM generation, artifact signing, provenance records in the pipeline | Syft, Cosign |
| Observability | Dashboards, alerts and service level objectives built into the template | Prometheus, Grafana, OpenTelemetry |
| Delivery metrics | Lead time, deployment frequency, change failure rate and time to restore, collected automatically | Your Git and CI data, plus a dashboard |
Process work happens alongside the tooling, since a pipeline nobody trusts won't get used. That means release and rollback procedures, on-call arrangements, an intake process for platform requests, and runbooks, all written with your engineers.
On day 90, can you open your repositories and find the pipeline definitions, infrastructure modules and templates the engagement produced, and can your own engineers change them without calling the consultants? If not, you bought advice.
What you should be holding at day 90
Agree the deliverables in the statement of work, and put the due dates next to them. Vague deliverables are how a consulting engagement quietly becomes a time-and-materials arrangement.
| Deliverable | What good looks like | Due |
|---|---|---|
| Baseline report | Numbers pulled from your own repositories, pipelines and incident history, with the friction ranked by cost | Day 15 |
| Golden path spec and decision log | One page of scope, plus the build or adopt reasoning for each major component | Day 30 |
| Golden path v1 in production | At least one business-relevant service running on it, not a sample app | Day 60 |
| Working implementation in your repositories | Pipelines, infrastructure modules, templates, policies and dashboards, committed to your repos and running in your environments | From day 60 |
| Adoption and outcome data | Teams and services on the path, time to first deployment before and after, re-measured delivery metrics | Day 80 |
| Ownership model and runbooks | Named owners, on-call rota, intake process for requests, and docs your own engineers wrote or edited | Day 90 |
| Two-quarter roadmap | Ranked by measured pain, with rough sizing and dependencies | Day 90 |
Notice what's absent: a 60-page target-state architecture document. Some written design is useful, and a one-page spec per golden path is plenty. The evidence that matters is a team shipping on the path and the numbers moving.
What 90 days will not do
It won't give you a finished platform. It gives you the first golden path, a repeatable way to add more, and evidence about what to build next. Anyone promising a complete internal developer platform in a quarter is selling either a very small platform or a very large change order.
It won't fix a culture where teams distrust each other, and it won't settle the argument about who owns infrastructure. An outside team can surface that argument fast, which is useful, but resolving it is a leadership job.
Migrating your whole estate is also off the table. Expect the launch team plus two or three follow-on teams. Everything else goes on the roadmap, sized and ordered.
Setting these expectations early saves a lot of awkward day-90 readouts.
Ask your sponsor to write the day-90 success statement as a single sentence. If it contains the word "complete" or "all," rewrite it before anyone signs.
How to tell a real engagement from a slide deck
The market for platform engineering consulting is young, and plenty of firms have rebadged older DevOps or cloud migration offerings without changing how they work. The differences show up fast if you know where to look.
| Signal | Weak engagement | Real engagement |
|---|---|---|
| First two weeks | Workshops and a maturity score from a questionnaire | Interviews plus numbers pulled from your Git, CI and incident data |
| Tool choice | Tool selected before the problem is named | Problem ranked first, then build or adopt reasoning for each component |
| What you receive | A strategy deck and a target-state diagram | A running path that a team used to ship real work |
| Commercial terms | Fees for advice paid up front, with no link to results | A scoped pilot paid for only if it succeeds, then a 90-day agreement signed after |
| Implementation | Recommendations and diagrams, with someone else left to build them | Pipelines, infrastructure code and tooling written in your repositories |
| Who does the work | Senior people sell it, juniors deliver it | Named engineers, introduced before you sign |
| Handover | A documentation dump in the final week | Your engineers pairing from week one, so there's nothing to hand over at the end |
| Success measure | Features delivered, tickets closed | Adoption by teams and movement in lead time |
One question cuts through most of it: ask to speak with the engineer who will be writing code in week five. If nobody can give you a name, you've met the sales team, not the delivery team.
Build in-house, hire a consultant, or both
Building in-house works when you already have a platform lead who's done this before and at least three engineers with real time to spend. Most mid-sized companies have neither, and the cost of learning on the job falls on the product teams waiting for tooling.
Outside help earns its fee when nobody on staff has built a platform, when a date is forcing the pace (a migration deadline, a regulatory milestone, a funding round), or when internal politics make an outside voice easier to hear. The most common setup combines the two: consultants plus two named internal engineers, pairing from day one so that knowledge moves in the right direction.
Cost is hard to state honestly without scoping. The drivers are the number of teams involved, how much must be built rather than configured, how tangled your CI and cloud estate is, and the weekly senior hours you need. With Stonetusker, the pilot comes first and is paid for only if it succeeds, and the 90-day agreement is signed afterwards, so the larger spend follows evidence.
Ask each shortlisted firm for a reference who adopted the platform after the consultants left, and ask that reference what changed in the six months afterwards. Reports about launch day tell you little.
Why compliance teams care about platform work
A golden path is the cheapest place to put supply chain controls. Generate the SBOM, sign the artifact and record provenance once in the pipeline template, and every service built from it inherits those controls. CISA published its 2026 Minimum Elements for an SBOM as final guidance on 29 July 2026, adding fields such as component hash, component licence, the name of the generating tool and an author signature, so buyers have started asking. Our write-up on the CISA SBOM minimum elements covers the details, and CISA's own SBOM resources are the primary source.
If you ship products with digital elements into the EU, the Cyber Resilience Act's reporting duties for actively exploited vulnerabilities have applied since 11 September 2026, with an early warning due within 24 hours and a fuller notification within 72. Whether it covers your product is a question for your counsel. Our CRA reporting guide covers the engineering side.
- Platform engineering consulting
- Internal developer platform
- Golden path
- 90-day roadmap
- DORA metrics
- Success-based pilot
- Hands-on implementation
- Launch team
- Ownership model
- SBOM
- Build vs adopt
Frequently asked questions
How much does platform engineering consulting cost, and when do we pay?
Cost depends on scope far more than on a rate card, so be wary of anyone who quotes a number after a short call. The main drivers are how many teams are involved, how much has to be built rather than configured, how tangled your CI and cloud setup is, and how many senior hours you need each week. With Stonetusker the engagement starts with a scoped pilot, and you pay for the pilot only if it completes successfully against success criteria agreed in writing beforehand. The 90-day plan is signed only after that.
How long does a platform engineering consulting engagement take?
Ninety days is a common length because it's enough to put one golden path into production and get a few teams using it. It comes after a scoped pilot, and the 90-day plan is signed only once that pilot has succeeded. Plenty of organizations then continue with a lighter retainer or a second phase for the next two quarters of roadmap. Anything much shorter than 60 days is usually an assessment, and anything open-ended tends to drift.
What's the difference between platform engineering consulting and DevOps consulting?
DevOps consulting usually improves how a particular team or pipeline works. Platform engineering consulting builds a shared, self-service layer that many teams use, and treats those teams as internal customers. In practice the skills overlap heavily, but the deliverable differs: a platform engagement ends with something other teams adopt on their own, plus an ownership model for it.
Do we need a platform team before hiring a consultant?
No, but you need at least two named internal engineers who will own the result. A full platform team can come later, once the first golden path has shown there's demand. If nobody inside will inherit the work, the platform tends to decay soon after the engagement ends.
What should we prepare before the engagement starts?
Line up an executive sponsor who has authority over at least two delivery teams, name the two internal engineers, and choose a launch team with a real deadline and a real complaint about deployments. Grant read access early to repositories, CI history, cloud accounts and the last two quarters of incident records. Slow access in the first week is the most common reason a 90-day plan stretches.
What results should we expect after 90 days?
Expect one golden path running in production with real services on it, working pipelines, infrastructure code and tooling committed to your repositories, a measured before and after for lead time and time to first deployment on new services, a named owner and on-call arrangement, and a ranked two-quarter roadmap. A credible firm won't promise a specific percentage improvement before looking at your data, because the baseline differs so much between organizations.
Weighing a platform engagement for your teams?
If your engineers lose days to environment tickets and hand-built pipelines, and you're deciding whether to staff a platform team or bring in help first, talk to us. Bring your current delivery numbers if you have them. We'll tell you plainly whether an outside team makes sense or whether you're better off starting in-house. If it does, we start with a pilot you pay for only if it succeeds, and you sign the 90-day plan after that.
Talk to Stonetusker about a pilot
