Engagement model / How we work
Six ways to work with us, and when each one is wrong.
Most of these are ordinary arrangements. What matters is picking the one that matches how well the problem is understood, because a fixed price around an unknown problem serves nobody.
How does TechSteps structure its work?
TechSteps works through fixed-scope projects, bounded technical audits, monthly engineering retainers, managed infrastructure agreements, security retainers and search retainers. Which one fits depends mainly on how well the problem is already defined. A clear deliverable suits a fixed scope. An unclear symptom is cheaper to diagnose with an audit first. Ongoing operational responsibility suits a retainer.
Engagement types
-
01
Fixed-scope project
A defined outcome with a clear finish line.
- Typical work
- A new website, a migration, a plugin, a hardening pass, a redesign.
- How it is shaped
- We agree the scope, the deliverables and what is explicitly out of scope before starting. Changes that materially expand the work get quoted rather than absorbed silently.
- When it is the wrong choice
- Fixed scope needs a well-understood problem. If nobody knows why the site is slow yet, an audit first is cheaper than a project priced around a guess.
-
02
Technical audit
You need to know what is actually wrong before committing budget.
- Typical work
- Performance investigation, security review, infrastructure assessment, pre-purchase due diligence, SEO and migration risk review.
- How it is shaped
- A bounded investigation producing prioritized findings, the evidence behind each one, and what remediation would involve. You own the output and are free to implement it elsewhere.
- When it is the wrong choice
- An audit is diagnosis, not treatment. We will tell you upfront if we expect the findings to be minor.
-
03
Engineering retainer
Ongoing development capacity without hiring.
- Typical work
- Continued product work, iterative improvements, integrations, technical debt.
- How it is shaped
- An agreed block of engineering time each month against a prioritized backlog you control. Unused capacity is discussed rather than quietly billed.
- When it is the wrong choice
- Retainers work when someone on your side can prioritize. Without that, the time gets spent on whatever is loudest.
-
04
Managed infrastructure
The server needs an owner.
- Typical work
- Patching, monitoring, backup verification, certificate renewal, capacity review, incident response.
- How it is shaped
- We take operational ownership of defined systems, with agreed response expectations and documented access. What we monitor and what we do not is written down.
- When it is the wrong choice
- We need real access to take real responsibility. We cannot own uptime for a system we can only see through someone else.
-
05
Security retainer
Risk that needs continuous attention rather than an annual review.
- Typical work
- Ongoing monitoring, vulnerability triage, hardening iterations, incident support, evidence for compliance reporting.
- How it is shaped
- Continuous monitoring plus a regular remediation cycle. Findings come with a decision, not just a severity label.
- When it is the wrong choice
- Security work changes systems. We agree in advance which actions are automatic and which always need a human.
-
06
Search retainer
Compounding search growth that depends on technical change.
- Typical work
- Technical fixes, information architecture, content engineering, measurement, ongoing expansion.
- How it is shaped
- A cycle of technical work, publishing and measurement, where new pages are added because demand was observed rather than because a keyword tool suggested them.
- When it is the wrong choice
- Search is slow and partly outside the control of any agency. We report what moved and what did not, including the months where nothing did.
Pricing
We do not publish price bands we cannot stand behind.
There are no rate cards on this page. Publishing an invented "starting from" figure would tell you nothing useful, because the same request can be a two-day job or a two-month one depending on what is already in place.
What we will do is give you a real number quickly. A short conversation about the system is usually enough to scope the work, and if we cannot scope it responsibly we will say that an audit needs to come first rather than guess.
What affects the number
- How well the current system is documented
- Whether the problem is diagnosed or still a symptom
- Access, environments and who else needs to be coordinated
- Uptime constraints during the change
- Whether existing code can be built on or has to be replaced
What we commit to
- Scope, deliverables and exclusions written down before work starts
- Changes that expand the work quoted, not absorbed and billed later
- An honest answer when the work is outside what we do well
- You own the output, including audit findings, and can implement them elsewhere
What the first two weeks usually look like
- 01
A technical conversation
Not a sales call. We ask what changed recently, what has been tried and what the constraints are. This is usually enough to tell whether we are the right people.
- 02
Access and a look at the real system
Read-only access where possible. Assumptions about a system are cheap to make and expensive to be wrong about, so we prefer to look.
- 03
A written scope
What we will do, what we will deliver, what is explicitly excluded, and what we need from you. If a dependency on your side is on the critical path, it is named.
- 04
Start, with a rollback position
For anything touching production, the rollback path is agreed before the change, not improvised during it.
Not sure which one you need?
Describe the situation and we will tell you whether it is a project, an audit or an ongoing arrangement. That answer costs you nothing.