Four phases, clear artifacts, nothing hidden
The short version of how a TekPiq engagement actually runs — written for engineering leaders who've seen enough vendor decks to know what's real and what's wallpaper.
Discovery
1–3 weeks
We pressure-test the problem before committing to a solution. The output is a delivery plan you can take to procurement, not a deck.
- Stakeholder interviews with product, engineering, and ops
- Existing-system review: architecture, data flows, pain points, constraints
- User research or validation where the customer-facing shape is unclear
- Risk register, assumptions log, and a prioritized backlog
- Delivery plan with timeline, team shape, and budget
Design & architecture
2–6 weeks (parallel with early build)
Design and engineering work in one room. UX, data model, and system boundaries evolve together rather than sequentially.
- Low-fi → high-fi UX; decisions captured as design system primitives
- System architecture diagrams (C4 or similar), reviewed with your team
- API contracts, data schemas, integration plan — locked before heavy build
- Non-functional requirements: performance, SLAs, observability, security
- Technical spike on any unproven component before it's committed to the roadmap
Build
Sprints of 1–2 weeks, continuous delivery
Shipping working software every sprint. You see progress in a live environment, not in status slides.
- Sprint planning with your PM; committed backlog and success criteria
- Daily standups in your Slack or Teams; async-first writeups for distributed teams
- Code review on every PR; automated test gates before merge
- End-of-sprint demo + retro with a written summary (for people who skip the meeting)
- Staging environment mirrors production; you can click anything as soon as it's built
Launch & handover
1–3 weeks
Handover that actually works: your team can operate what we built on day one after we leave — or we stay on a retainer. Your call.
- Runbooks: deployment, rollback, on-call, common incidents
- Architecture doc + decision log so your next engineer understands the why, not just the what
- Knowledge-transfer sessions recorded for later hires
- Observability baselined: dashboards, alerts, error budget
- Optional post-launch retainer for patch work, enhancements, or on-call coverage
Seven-step transformation methodology
For larger transformation engagements — modernization, AI adoption, or end-to-end product rebuilds — the four-phase delivery cadence above runs inside this longer arc. The first three steps usually take 8–12 weeks combined and produce something live in production. The rest is operating cadence, not a Gantt chart.
Assessment
Current-state audit of systems, data, processes, and the people who run them — including the constraints nobody wants to write down.
Strategy formulation
Target architecture and a sequencing plan tied to a named business metric, not to 'going digital'.
Design & development
UX, architecture, and engineering in parallel — the first production-ready slice ships in weeks, not after the deck is approved.
Implementation
Incremental rollout via strangler-fig or feature flags. No heroic cutovers. Old surface retires only when the replacement is proven.
Training & adoption
Adoption is engineered, not hoped for: pilot groups, in-product onboarding, and training co-built with the team that has to live with the result.
Monitoring & feedback
Adoption and outcome dashboards from day one. If usage at month three is 20%, that's a bug to fix — not a people problem.
Continuous improvement
Quarterly review against the business metric. The system that ships isn't the system that operates a year later — and that's by design.
Operating model
Communication
We work in your tools — Slack/Teams for day-to-day, Jira/Linear/Notion for tracking, Git where it lives. We don't require you to come to our portal.
Visibility
Your team sees the same dashboards we do. Velocity, burn-down, and test coverage are live, not weekly PDFs. Sprint reports summarize the shape of the work, not the vibes.