How We Work

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.

The TekPiq office floor in East Sarajevo with engineers working at their desks — Our office floor in East Sarajevo - where every phase below happens.

The TekPiq team around the meeting-room table with laptops, a shared screen on the wall — In the meeting room.

1–3 weeks

Discovery

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

TekPiq engineers in an architecture session at the whiteboard, one of them sketching the data model — At the whiteboard - client details blurred.

2–6 weeks (parallel with early build)

Design & architecture

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

Hands on a mechanical keyboard in front of a laptop and monitor with code — Screens blurred - client code stays private.

Sprints of 1–2 weeks, continuous delivery

Build

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

Two TekPiq colleagues pairing on laptops at the meeting table — Pairing at the meeting table.

1–3 weeks

Launch & handover

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

Digital Transformation

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.

Step 1

Assessment

Current-state audit of systems, data, processes, and the people who run them - including the constraints nobody wants to write down.

Step 2

Strategy formulation

Target architecture and a sequencing plan tied to a named business metric, not to 'going digital'.

Step 3

Design & development

UX, architecture, and engineering in parallel - the first production-ready slice ships in weeks, not after the deck is approved.

Step 4

Implementation

Incremental rollout via strangler-fig or feature flags. No heroic cutovers. Old surface retires only when the replacement is proven.

Step 5

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.

Step 6

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.

Step 7

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.

Read the full Digital Transformation service

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.

Start with a scoping call

30 minutes. We'll ask about the problem, the constraints, and what "done" looks like - and tell you which phase we'd start in and what it would cost to find out.