Working With Us
How an engagement starts, how a project runs, and what happens after launch.
How does a project with MS WebX start?
You describe the goal, not the technical solution. We ask questions until the scope is actually clear, then put it in writing before anything is built. If we think what you asked for is the wrong way to reach your goal, we say so before you pay for it — that conversation is cheaper than the rebuild it prevents.
How does a project run day to day?
In small, visible steps. Work goes to a staging environment you can open in your browser whenever you want, and it reaches the live site only when you say so. Nobody is shown a finished product for the first time at the end of the project — by then it is too late to change anything cheaply.
What happens after launch?
What we build is meant to be maintained: dependency updates, monitoring, and changes as your business changes. Whether we keep doing that or your own team takes over is agreed as part of the project, not assumed afterwards. Nothing is built in a way that only we can touch.
Can you take over a system somebody else built?
We read the existing code first and then say plainly whether continuing it or replacing it costs less over the life of the system. Both answers happen — an inherited codebase is often perfectly fine and just badly documented. We do not recommend a rebuild by reflex, because a rebuild is the most expensive thing anyone can sell you.
What do you build on, and how do you keep quality up?
PHP on the server, TypeScript in the browser, Flutter for iOS and Android, MariaDB for data, nginx and FrankenPHP for serving. Current, widely known technology on purpose, so anyone can maintain it after us. Quality is enforced by machines rather than good intentions: static analysis runs at its strictest level with no suppression list, alongside more than two hundred project-specific rules that reject code the moment it drifts.