Start a project.
Send the problem. We reply with whether it should be AI, software or automation, what we would build first, how long it takes, and the tools we would use.
Five short answers.
Name. Who you are and where the reply should go. Any name is fine.
Email. Where we send the reply. This is the only field that is strictly required.
Area. The nearest fit from the list. A wrong guess costs nothing; the description corrects it.
Budget. A range, or not decided yet. We scope against it rather than quoting against it.
Project. The problem itself. Two sentences is enough; a paragraph is better.
A reply, not a pitch.
We reply to every enquiry. If the answer is that this should not be built yet, that is the reply, and it is worth having before you pay someone to tell you it is a great idea.
Diagnosis. Whether this should be AI, software, automation, or none of the three. We say so directly.
Scope. The smallest version worth building, and what we would deliberately leave out.
Tools. The actual technologies we would use and the reasons for each choice.
Timeline. A realistic sequence in working increments, with the riskiest part first.
Each field changes the answer.
The form is short on purpose, but every field does work. The area selects which piece of our practice looks at your message first, so the diagnosis is not generic. The budget range decides whether we propose a system you build once or one you grow into, which is a different engineering decision.
The project text is where almost all of the signal lives, which is why it is the only open field. Two sentences describing the workflow is genuinely enough to give you a direction; the more specific you are about where the answer has to end up, the better the scope comes back.
Name. A name, not a person. It keeps the reply readable when more than one of you sends the same problem.
Email. The reply goes here. It is the one field we validate, because without it there is no reply.
Area. Pick the nearest match. A wrong guess is corrected by the project description, never by a phone call.
Budget. A range you can live with. We scope against it and say plainly if the work is outside it.
Project. The constraint itself. The more specific you are, the less you have to explain in round two.
There is no reason to ask.
This form does not ask for a phone number, because nobody here calls you to sell something. It does not ask for company size, because we scope the work, not the account. It does not ask for a deadline, because a deadline you did not set is not a useful constraint.
There is no newsletter opt-in and no marketing preference. If you send a project message, you get a reply about the project. That is the entire data flow in both directions.
A conversation, not a contract.
There is no onboarding call you are expected to take, and no proposal template. The reply is the start of a working conversation: you send more context, we refine the scope, and at some point you say go and the first increment starts building.
Every engagement runs the same six moves: discover, design, build, deploy, learn, scale. Each has an exit condition, so nothing advances on enthusiasm, and nothing loses its spec halfway through.
More practice areas.
These services share the same stack and the same pipeline, and they usually show up in the same engagement.
Send the problem.
Five short answers. No requirements document, no timeline and no budget range needed to get a reply.