01 / Approach
How a Tekstak engagement actually runs.
Five things every prospective client wants to know before they sign. Five things we'd want to know first if the roles were reversed.
02 / How we scope work
How we scope work.
A real conversation first. Documents second. Code third.
Every engagement starts with a discovery conversation — not a discovery workshop, not a sales call. The people who will actually write your software sit down with the people who will actually use it, document the workflow, map the constraints, and tell you honestly whether we can help.
Out of that conversation comes a written scope: what we'll build, what we won't, what the constraints are, and how we'll know it's done. If the scope feels wrong, we change it before we quote on it.
03 / Fixed price vs time and materials
Fixed price vs time and materials.
Fixed price where we can. T&M where we have to. Honest about which is which.
Most engagements are fixed price. If the scope is clear enough to write down, the price should be clear enough to write down. No T&M creep, no surprise change orders mid-build, no hourly bills that grow faster than the software.
Some work doesn't fit a fixed price — open-ended discovery, exploratory integration, long-running support. For those we use time and materials, with a written cap and weekly visibility into what's been spent. We won't dress up T&M as fixed price; we won't dress up fixed price as T&M.
04 / Code and IP ownership
Code and IP ownership.
You own everything. Source, schemas, documentation, deployment scripts.
When the engagement ends — or any time during it — you own the code, the database schemas, the documentation, the deployment scripts and the keys. We don't license what we build back to you. We don't keep the source on our servers as leverage. We don't gatekeep your own software.
This is written into every contract. There is no 'platform' you stay locked into, no annual licence renewal that disguises a hostage situation. The work is yours.
05 / Sprint cadence
Sprint cadence.
Two-week sprints. Production from sprint one. You see the work as it lands.
Work happens in two-week sprints. Each sprint ends with something deployed — not necessarily released to your users, but running in an environment you can see and test against.
There is no six-month invisible phase. There is no big-bang launch. The system grows in the open: you see the increments, you give feedback inside each sprint, you redirect the work before it gets expensive to redirect.
06 / Support after handover
Support after handover.
Same team, same phone number. Written into the same contract as the build.
Support isn't a separate sale. The same engineers who wrote the code answer the phone when something breaks at four in the morning. The knowledge stays attached to the system that needs it.
We cover monitoring, capacity planning, incident response, security patching and steady reduction of technical debt. Most clients stay on a support contract for years after handover — because the people who built the system are still the cheapest, fastest people to maintain it.