What Happens When You Hire SpiderHunts

Nobody should have to guess what they are buying

The most common thing we hear on a first call is some version of “we tried an agency before and we never really knew what was happening.” That is a process failure, not a technical one. Software is invisible until it is finished, so the only thing keeping a client oriented is a rhythm of visible checkpoints — and most engagements do not have one.

This page is our answer to that. It is the actual shape of a SpiderHunts engagement, written down so you can hold us to it. Nothing below is aspirational; it is what happened on the last dozen projects, including the parts clients find inconvenient.

Days 1–5: discovery, and a number you can rely on

The first call is 30 minutes and free, and its only purpose is to work out whether we are the right people. About one in five of those calls ends with us saying no — usually because the work is a better fit for an off-the-shelf product, or because the budget and the ambition are too far apart to close honestly.

If it goes forward, discovery is a longer session where we map what exists now: the systems, the spreadsheets, the people who do the manual steps and the reason each one exists. That last part matters more than it sounds. Most “irrational” manual processes turn out to be compensating for something real, and automating them without understanding why produces software nobody trusts.

You end that week with a written proposal: scope, exclusions, a fixed price, a timeline with dates, and the assumptions the price depends on. If an assumption turns out to be wrong we tell you before it costs anything, not in an invoice three months later.

• What we will build, in plain sentences rather than feature bullet points
• What we will not build, which is usually the more useful list
• A fixed price, or a capped range where the unknowns are genuinely unknowable
• Milestones with dates, and what you get to see at each one
• The stack we intend to use, and why that one

Days 6–10: architecture before implementation

The second week produces the things that are expensive to change later: the data model, the API contracts, the integration points and the wireframes for every screen. You approve these before a line of production code exists.

This is the week clients are most tempted to skip, and the week that saves the most money. Changing a database schema in week two costs an afternoon. Changing it in week ten costs a fortnight, because by then six things depend on it. We have never regretted spending a week here.

A wireframe you disagree with in week two is a success. It means the disagreement happened while it was still free.

Days 11–30: the first sprint, and the first thing you can click

We work in one- or two-week sprints. Each one ends with a demo of working software on a staging URL you can open on your own phone — not a slide deck, not a progress percentage. Between demos you get a short written update twice a week: what moved, what is blocked, what we need from you.

The first sprint deliberately targets the riskiest part of the system rather than the easiest. If an integration with your accounting package is going to be a problem, we would all rather find out in week three than week eleven. This is why the first demo sometimes looks unglamorous — a working data pipeline with an ugly interface is a better week-three result than a beautiful login screen.

By day 30 you should have: a staging environment, a repository you own, a working slice of the core feature, and a clear view of whether the timeline in the proposal is still right.

Who you actually talk to

You get a named lead engineer and one point of contact for commercial questions, and they do not change mid-project unless something serious happens. There is no account manager relaying messages between you and the people writing the code, because that layer reliably turns a five-minute clarification into a three-day round trip.

For a small project those two people may be the whole team. For a larger one there will be two to four engineers, a designer and a QA pass, but the interface to you stays the same size.

What we need from you

The honest answer is: less time than you fear, but at predictable moments. Roughly two hours a week — one demo, one round of feedback — plus fast answers on decisions only you can make.

The projects that go badly are almost never the technically hard ones. They are the ones where a decision sat in someone's inbox for three weeks while the team worked around it, and the workaround became permanent.

• One decision-maker who can approve scope changes without a committee
• Access to the systems we need to integrate with, arranged in week one
• Sample data — real, messy data, not a tidied-up example
• An hour at each demo, from someone who will actually use the thing

What happens if it goes wrong

Some things always go wrong. A third-party API is undocumented, a data migration reveals fifteen years of inconsistency, a requirement turns out to mean two different things to two departments. What matters is what happens next.

Our rule is that bad news travels immediately and in writing, with options attached. You will never learn about a slipped milestone at the milestone. If the cause is on our side, we absorb it — a fixed price means fixed. If it is a genuine scope change, we price it separately and you decide whether it is worth it.

Frequently asked questions