Radical transparency

Why you might not want to hire Devntech

Most agency websites are a list of reasons to say yes. This is the other list. If two or three of these describe your situation, we would rather you knew now than after a call - and we will tell you the same thing on the call anyway.

We’re probably not a fit if

Seven situations where we would tell you no

  • You want a one-off demo, and nobody will own it afterwards.

    A demo has no owner and no measurable outcome, whether it is a chatbot or a prototype screen. Somebody will build you one cheaply and it will sit unused. Spend the money on work with a number attached.

  • Nobody inside the business owns the process, the product or the codebase.

    Without an internal owner there is nobody to answer the questions the build surfaces, nobody to approve a change to how the work is done, and nobody to keep the improvement going after we hand over the result.

  • We cannot reach the people who do the work, or the code that already runs.

    A workflow map is only accurate from the people doing the work, and a codebase assessment only if we can read the codebase. Built from a description, either one misses the exceptions - and the exceptions are where these projects fail.

  • There is no measurable reason to build it.

    If we cannot state the number we are trying to move, we cannot tell whether it worked, and neither can you. That makes it a technology purchase rather than an improvement to the business.

  • You need a large consulting presentation rather than an implementation.

    We are an implementation company. If you need a strategy deck and a steering committee, there are excellent firms for that, and we are not one of them.

  • You expect the software to fix a problem the software is not causing.

    Automating a broken process makes it produce wrong results faster and at greater scale, and rebuilding a product nobody wanted produces a better version of the same thing. Where the process or the proposition is the problem, we will say so before building anything.

  • You are not prepared to measure the result.

    Measurement is not overhead we add to justify our fee. It is the only way to know whether to expand, adjust or stop - and a client who will not measure cannot make that decision.

On the other hand

What a good fit looks like

If most of these are true, the first conversation is usually short and productive.

  • The work recurs: a workflow that runs many times a week, or a product with a roadmap behind it.
  • The rules or the requirements are stable enough to write down, even if nobody has written them down yet.
  • One person owns the process or the product and can make decisions about changing it.
  • You can put a number on what it costs today, or you are willing to measure one.
  • You want the system operated after launch, not handed over and forgotten.
  • You would rather hear "do not build this" than be sold something.

If you read that and thought “that’s us”, let’s talk.

Describe the process, the product or the codebase. If we are the wrong choice we will say so on the first call, and point you at what we think you actually need.

  • For established businesses from $5M in revenue, and products that are live, business-critical or already depended on
  • No long-term commitment
  • Start with one workflow or one system
  • Keep ownership of everything we build