Decide whether to build at all
Part of our job is telling you not to build it. If a standard product covers 80 %, adapting to it almost always beats maintaining your own code for years.
First we check whether something already solves it, because it usually does and it's cheaper. When it doesn't, we build: with code that is yours, documented, and no dependencies you can't maintain.
Part of our job is telling you not to build it. If a standard product covers 80 %, adapting to it almost always beats maintaining your own code for years.
Customer portals, internal tools, SaaS platforms. With real authentication, role-based permissions, and designed for people who aren't technical.
What connects your system to the rest: payment gateways, e-invoicing, ERP, CRM. With a documented API contract, versioning and error handling that doesn't swallow failures.
Field capture, working offline, syncing when the signal returns. Before a native app we check whether an installable web app solves the same thing for half the cost.
Tests, automated deployment, error logging and documentation. A system without those works on day one and causes trouble every day after.
Everything below is in real projects. If something isn't on the list, we tell you before we start and not after.
You do, from the first commit, in your repository. We hand over code, technical documentation and access. We don't use licences that tie you to us and we don't leave closed parts.
Budget 15 to 20 % of the build cost per year, between dependency updates, small changes and fixes. Anyone who doesn't give you that figure when quoting will charge it later anyway.
Yes, interface and experience included. We are not a brand studio: if you need full corporate identity, we work with your designer or recommend one.
Yes, and it's more common than it sounds. We start with a code review and tell you frankly what can be salvaged and what is cheaper to rebuild. Sometimes the answer is uncomfortable.
We deliver in working blocks, with a demo every two weeks and priorities that can be revised. What we don't do is use «agile» as an excuse to avoid committing to scope or a date.
Twenty minutes is enough to know whether there's a project. If there isn't, we'll say so.