Practice 01
Internal tools, APIs, dashboards and business applications built to a fixed scope, delivered working, and handed over with the source code and the documentation to keep them running without us.
Scope agreed in writing before work begins.
The problem
Most internal software starts as a spreadsheet someone built in an afternoon. Then a second file references it, then a macro, then a shared drive nobody dares reorganise. By the time it breaks, four people depend on it and none of them can explain how a number is produced.
The fix is not a bigger spreadsheet. It is a small, well-scoped application with permissions, logs and an audit trail — built to be handed over, not to make you dependent on whoever wrote it.
Scope
Stated before you ask, so the first call is about your problem rather than about what we do or do not cover.
How it runs
We sit with the people who run it today and map what actually happens, including the workarounds nobody documented.
Features, data model, integrations and what is explicitly out. You approve it before a line of code exists.
Working software every week or two, not a demo at the end. If it is going the wrong way you find out early, when it is cheap.
Repository, documentation, credentials and a working session with whoever will maintain it. Our access is revoked at closure.
Track record
As a certified Scrum Master at a software company, ran four delivery workstreams simultaneously — a CRM platform, a career-path dashboard, a time-off management system and a document-generation tool — owning estimates, cross-team dependencies and every Agile ceremony, tracked in Jira and Confluence.
Mechatronics engineer with full-stack web development training. Recent build: a packaged desktop application for goods sold by weight, combining a React/Vite front end, a FastAPI and SQLAlchemy back end, SQLite, JWT authentication and Tauri packaging.
Delivery commitments grounded in real internal cost rather than optimism — which is what keeps dates credible with clients and leadership when something slips.
Questions
Python with FastAPI on the back end, React on the front end, PostgreSQL or SQLite for data, and Tauri when the result needs to be an installable desktop app. The stack is chosen for what your team can maintain, not for what is fashionable.
Yes. It usually starts with a short assessment to read the code, understand what it does and tell you honestly whether extending it or replacing it is the cheaper path.
It gets re-quoted in writing before the work starts, not absorbed silently and billed later. Changes are normal; surprises are not.
You do, from the first commit. The repository, documentation and credentials are yours, and any access we hold is revoked when the engagement closes.
Start here
Describe the problem in a few lines. You get a written reply with a first read on it, whether or not there is an engagement in it. The message is sent from this page — no email client, no third-party form service, no trackers.