The four engagements Assessment
Assessment
Five working days, from the day I have access to the application. Fixed price: €490. No VAT is added. Credited in full against anything you commission from it within six months. I invoice once we have agreed a start date.
Before anything is automated, somebody has to decide what is worth automating. That decision determines whether the suite is alive in a year, and it is the one most often skipped.
What I read
The application itself. Whatever documentation exists — technical and business, including the parts that contradict each other. The way your team actually releases, which is rarely the way the process says. Your bug history. And whatever automation already exists, if it does.
Bug history is the most useful of these and the one teams hand over last. It is a record of what really breaks, written by the people it broke for.
What I check
A few hours inside the application itself, once I have access. Enough to turn part of the trap catalogue from a guess into a fact — not enough to call it a full pass, and I don't call it one.
What gets confirmed is priced in hours. What doesn't stays labelled a guess, instead of being priced as if it were certain.
What I decide
Which flows carry enough cost of failure to be worth covering, and in what order — ranked by what a failure costs you, not by what is easy to automate. Those two lists rarely agree, and the second one is how suites end up covering the settings page and not the checkout.
Which flows are not worth covering at all. That list is usually longer than the first, and saying so early is cheaper than discovering it on week five.
Then which layer each check belongs at — interface, API, or the database underneath — and which tools fit your stack. A tool that is fashionable and a tool that fits are sometimes the same and often not.
What you get
- An inventory of the application, flow by flow, ranked by cost of failure: your numbers, my ordering. Set against what covering each flow costs in hours, that ordering shows where the quick wins are and where the expensive necessities are.
- A trap catalogue: what will fight the tests in this codebase, each marked verified or unverified, priced in hours where it is verified.
- The flows I would not automate, named, with the reason for each.
- Tool selection for this stack, with the options I rejected and the reason for each.
- Two or three options for what to build, each with a scope in flows, a calendar estimate and a price.
- If you build it in-house instead: where to start, in what order, and what to avoid.
- The state of your test data and environments — what makes a run repeatable today, what does not, and what would have to change before anything runs twice and gives the same answer.
- The specification gaps I found: where the documents contradict each other, and where the few hours I spent in the application showed they contradict the application too.
If the answer is that you do not need me, that is in the document too.
Fixed price, and credited in full against any work you commission from it within six months. If you commission nothing, the document is still yours: take it to your own engineers and build it in-house, and we are square.
The fee is earned before you decide anything, on a fixed scope regardless of what you do next — an analysis that only pays for itself when it produces a sale is one you would be right not to trust.
What I need from you
- Access to the application — staging or a demo instance, with data.
- Whatever documentation exists, including none.
- The form, filled in. That is the conversation.
No discovery call. The questions in the form do the same job, and you keep your calendar. If something needs clarifying I will ask it in writing.
Show me the application.
Seven questions. No discovery call — the answers here do the same job, and you keep your calendar.
For an assessment, question two — your stack — is what decides how much of the trap catalogue I can confirm rather than guess at.
Only three answers are required — your stack, the list of things people do, and what a failure costs. An incomplete form beats an unsent one.
Not ready to scope anything? Write anyway. I will tell you what I would do first, and you can come back when it matters.
What gets composed — in your mail client, not sent anywhere by this page
This form builds an email in your own mail client — there is no form service behind it, no endpoint, and nothing reaches this server. It needs JavaScript. With scripts off, write to the address below and answer the seven questions above in your own words.
If staging does not exist, say so — it changes the scope or the calendar, and I will tell you which before we start, not on week three.