A manual process has outgrown a spreadsheet
It's still technically working; everyone involved knows it won't survive another six months of growth.
Enterprise engineering
Build software around the work it needs to do.
When manual work or a platform limitation is holding a process back, Kritical builds maintainable software, automation or platform extensions that give the team a workable result, with ownership and support arrangements agreed before delivery, not discovered after.
On this page
Choose where to start.
Jump to the part that matches the problem or decision in front of you.
Use the arrows or scroll to see every card.
Three situations bring people to this page.
A platform's built-in features stop short of the actual requirement
A platform may cover much of the requirement; a defined remaining gap may need custom work.
Nobody currently owns a piece of software that runs the business
The person who wrote it has left, and its behaviour is now folklore rather than documentation.
What you get: a scoped requirement, not an open-ended build.
Start with the user or operator task, the systems involved and the result that must be produced. We identify permissions, data ownership and the consequences of failure. A scoped requirement also describes what the software won't handle initially, allowing a useful first release without hiding unresolved dependencies. Release notes and a clear rollback or recovery approach help the operating team understand each delivered change.
User or operator task
Start with the user or operator task.
Systems involved
Identify the systems involved.
Result to produce
Define the result that must be produced.
Permissions and data ownership
Identify permissions and data ownership.
First-release boundary
Describe what the software will not handle initially.
Why Kritical: we pick the implementation that fits the environment, not our favourite stack.
The work may involve a service, application extension, API integration or operational automation.
PowerShell, C#, TypeScript, JavaScript and Business Central AL
Kritical's engineering scope covers the languages your actual platforms need, checked against existing capability before adding custom code.
Existing platform features assessed before new code
We check what the platform already does before recommending you pay to build it again.
Our own Shopify-to-Business Central connector as proof of the discipline
Built by Kritical, then verified against representative customer scenarios, including agreed failure cases, before go-live.
Testing the behaviour that matters.
Verification covers representative use, permission boundaries and material failure cases. We define how changes are reviewed and how defects are reproduced. For automation, this includes partial completion, reruns and the information an operator needs to recover. The test plan is proportionate to the consequences of the software changing a real system.
How it's priced, and what handover looks like.
An agreed handover is quoted in writing and can include source code, dependency information, build and deployment instructions, test evidence and known limitations. We confirm ownership, licensing and support arrangements in the engagement. Ongoing maintenance, hosting and feature development are explicit decisions, including who responds when a dependency or platform API changes.
First call
We confirm the task, the systems it touches and the consequences of it going wrong.
Get a quote
Send the systems and constraints involved and we quote the work.
Questions before you enquire
Can you extend software we already have?
Yes, subject to access, licensing and the available extension points. An initial review can establish the safest and most maintainable approach.
Who owns the delivered code?
Ownership and licensing are agreed in the commercial terms, including any existing Kritical components and third-party dependencies.
Can you automate an existing manual process?
Yes. Start with the process, source data, exceptions and approval requirements. We can determine which steps are suitable for automation and how to verify the result.
Do you build Business Central extensions specifically?
Yes, in AL, alongside our own Shopify-to-Business Central connector work, checked against your specific configuration and customisations first.
What happens if the person who understands the code leaves?
The handover documentation is written for exactly that scenario: source code, build instructions, known limitations and support arrangements recorded up front, not carried in one person's head.
Can you take over software someone else built for us?
Yes, subject to access, licensing and the state of the existing code. An initial review establishes what's there before we commit to extending or replacing any of it.
Do you write automated tests, or just check things manually before release?
Automated tests are scoped where the consequence of a regression justifies them. The test plan is proportionate to what the software does to a real system.
Let’s define the next step.
Tell us what you want to achieve, what you have today and when it matters.