CUSTOM DEVELOPMENT & MODERNIZATION
A new business application, an extension of the product you already sell, or a modernization of the system you run today. .NET is the target stack; the system you start from can come from any technology, and the work begins with understanding it. Web, Android and iOS, integrations and practical AI features are part of the toolbox, used where the project needs them, not by default.
Scope, phases, timeline and pricing are agreed per project, after discovery or an assessment.
// three starting points
The same person does the work in all three cases. The first step is different.
Discovery comes first: who uses it, which process it runs, what has to exist on day one and what can wait. From that comes a scope with phases, a timeline and a price. If the first version fits a fixed functional scope for web, iOS and Android, the 14-business-day MVP may be the better offer; if it does not, this is the right one.
A new module, a mobile app on top of a web product, an integration with a system you cannot replace. The existing code and data stay the starting point. New parts are built behind clear interfaces, with tests, so they can be released without touching what already works.
An assessment comes first: inventory, risks, the order of work and the behaviours that must not change. Then the system moves to .NET in increments that keep it running, with the database kept where it works. The source technology can be anything; it is analysed, not assumed.
// what the work can include
The scope determines which capabilities your project needs, and the plan says which of these it gets and why.
Two things I do not promise: that every source stack is one I know as well as .NET, and that every idea fits the first phase. The existing system is analysed and the approach planned around its constraints; the scope is agreed before the work, and new ideas go on the list for the next phase.
// variation without copies
Most business systems grew by copying. A second customer needed a slightly different approval flow, so the flow was copied. A new document layout was needed, so the generator was copied. Each copy then drifted on its own, and a rule change became a search across the codebase.
Where real variation exists across processes, entities or customers, the variation goes into configuration or metadata and the logic exists once. A workflow is a definition with steps, conditions and roles. A document is a template with data sources. The code that runs them is small, tested and shared. This applies to new systems as much as to modernized ones; in a new system it is cheaper, because nothing has to be untangled first.
// the process
For a new system: who uses it, which process it runs, what has to exist on day one. For an existing one: an inventory of modules, integrations and data flows, the risks ranked, the order of work, and the list of behaviours that must not change. Its scope and length are agreed with you, because they depend on the size of the system and how much of its behaviour is written down. The result is a plan with phases and an estimate for the first increments.
Each one is small enough to verify on its own, has tests that pin the behaviour, and is ready for the release schedule we agree. Feature work continues in parallel, planned against your team's capacity and the dependencies between the two streams. A fixed date, where you have one, is assessed against the scope and the dependencies before it is promised.
For each step that touches a running system the assessment says whether users are affected. Where a cutover needs a pause, it gets an agreed maintenance window, a rehearsal and a recovery plan.
Process improvements are decisions written down before the work, not side effects of a migration. Tests check both: parity where nothing should change, and the agreed new behaviour where it should. Data integrity is kept throughout. Transaction boundaries are kept as they are, or redesigned against consistency requirements we define together.
// measurable targets, not guarantees
Before the work starts we agree which of these to measure, and how. The numbers come from your system, not from a brochure.
| Area | Today, typically | >_ Target |
|---|---|---|
| Releases | Manual, infrequent, after hours. | Automated pipeline, routine, reversible. |
| Business rules | Copied across modules and procedures. | Shared, tested components where business rules have the same meaning. |
| Variants | A code branch or a copy per customer, product or region. | Configuration over shared logic. |
| Visibility | Logs on a server nobody reads. | Metrics, logs and alerts in your environment. |
| Platform | Out of support, hard to hire for, growing bill. | Supported .NET, predictable infrastructure. |
| Knowledge | In two heads. | In the repository, with the team. |
// optional
Some business systems have a job for a language model: reading supplier documents into typed data, drafting replies, answering questions over your own records. It is added where it solves a concrete problem, after the domain is clean enough to check the model's output, and the model can only call the methods you expose. How that looks in practice is the subject of the series LLM Inside the Monolith, built on a demo system you can run.
// background
Anonymised, from systems I have worked on. The source technology was different every time, and the approach was planned around each one.
Complex PL/SQL logic and data flows moved to C#/.NET with functional parity, under transaction and concurrency constraints, using reusable patterns so the same rule was not rewritten per module.
Analysis of existing Delphi business logic, ERP processes and data, and development of the C#/.NET web functionality that took them over.
Process analysis on site with the people running the lab, redesign of the laboratory workflows, the architecture that followed, and knowledge transfer to the team that maintains it.
Configurable templates and data sources, metadata-driven processing and runtime type resolution, so the engine supported different document types and sources without a separate implementation for each.
Business workflow modelling and integration with business and industrial systems.
A back office for a hardware reseller with a local language model inside, built in public as the system behind the blog series. Source on GitHub. It is a demo, not a client project.
// not a fit if
// straight answers
No. .NET is the target. The system you run today can be Delphi, Java, PHP, Oracle Forms or anything else, and it is analysed first; the approach follows its constraints. I do not claim expertise in every source stack. I claim a method for understanding one, and I say so when a system needs a specialist I am not.
Yes. A new business application or module starts with discovery instead of an assessment: who uses it, which process it runs, what has to exist on day one. Scope, phases and timeline follow from that, not from a fixed package.
No. The MVP is a separate offer with a fixed functional scope for web, iOS and Android. Custom development has scope, phases, timeline and pricing agreed per project, and a new product can be either, depending on what it has to do on day one.
Feasibility is assessed against the scope and the dependencies before anything is promised. If the date holds, it goes into the plan together with what it depends on. If it does not, you hear that before the work starts, with what would have to change.
Each step is assessed for impact before it is scheduled. Where a cutover needs a pause, it is agreed in advance, rehearsed, and has a recovery plan.
Yes. The work is planned in increments around your roadmap and your team's capacity, and the pipelines it adds make feature releases safer too.
No. The database and the procedures stay unless there is a concrete reason to move a piece of logic: it is duplicated, cannot be tested, blocks a change, or has to run outside the database.
I do, directly with your team: analysis, architecture, implementation and the handover of knowledge. Your developers work in the code with me, so the system stays theirs.
// start here
A new system, an extension, or one you want to modernize: what it does, what hurts, and what has to keep working. You get a straight answer on how I would approach it and what comes first.
A few sentences are enough: what it runs or should run, what is painful, and what must not break.
First questions, the risks I see, and whether discovery or an assessment comes first.
Scope, phases, timeline and pricing are agreed after it.
No sales reps. Direct talk with the lead architect.