Custom software Denmark

Custom software for companies that have outgrown standard tools.

UnderStack builds custom business software for the part of your operation that no off-the-shelf product handles well, and connects it to the tools you already use.

If you would prefer to talk through more details, we can find a time that works.

01

When custom software is worth it

Standard software is the right choice for standard problems: accounting, payroll, email. Custom software earns its cost where your process is what makes the company different, or where the gaps between tools are filled by people copying data. The signs are easy to recognise. A wholesaler keeps customer-specific prices in a spreadsheet beside the ERP. A property manager coordinates inspections in a shared calendar and a folder of photos. A production company plans capacity on a whiteboard because the planning module cannot handle its exceptions. A professional association manages members, events and payments in four subscriptions that do not talk to each other. If the team has built its own system out of spreadsheets, messages and memory, that system already exists. It is just unreliable, invisible to management and dependent on one or two people.

02

What a custom system typically contains

We keep the system as small as the process allows. Most custom systems are a combination of a few well-understood parts, shaped around your terminology and rules.

  • A data model that matches how your business describes its work
  • Roles and permissions per department, location or client
  • Screens for the daily tasks, built for the people who do them
  • Integrations with accounting, email, payment or existing databases
  • Reports and exports that replace manual monthly summaries
  • An audit trail of who changed what, and when

03

From workaround to working system

We do not start by collecting a wish list. We start with the workaround you have today, because it shows what the process really needs.

  1. 1Process review: we walk through the current spreadsheets, forms and messages with the people who use them. You receive a description of the process as it is and a list of what the first version must cover.
  2. 2Scope and quote: the first release is reduced to the part that removes the most manual work. You receive a written scope, the exclusions and a quote.
  3. 3Design of data and screens: the data model, the roles and the key screens are agreed before code is written. You receive the screen flows to review with your team.
  4. 4Build in iterations: each iteration delivers a usable part of the system in a preview environment. You receive a version to test with real data after every iteration.
  5. 5Migration and launch: existing data is imported, accounts are created and the old workaround is retired. You receive the live system and a walkthrough for its users.

04

Technology and technical decisions

Custom systems are built with React and TypeScript in the browser, Node.js on the server and PostgreSQL for data. The decisions that matter most are made in the data model: which records exist, who may see them and how they relate. In GastroApp, for example, a company has several restaurants, users are authorised per restaurant with one of six roles, and item prices feed recipe costs, stock and reports, so a figure is entered once and reused everywhere. We apply the same principle to every system. Existing tools are connected through their APIs, and where a legacy application has to stay, it is modernised in steps, as in the ongoing migration of the Peritar platform from PHP to TypeScript. Tests and a type check run before each deployment.

React
TypeScript
Node.js

05

Risks and how we reduce them

Custom projects go wrong in a few predictable ways. The scope grows because every department adds wishes, so we fix the first release in writing and keep a separate list for later. The system reflects how management thinks the work is done rather than how it is done, so we design with the people who do the work and test each iteration on real cases. The knowledge sits with one supplier, so the code is written in widely used technology with a clear structure that another developer can read. And data migration is underestimated, so existing data is examined at the start, not in the last week.

06

Budget and ownership of the decision

A custom system is an investment in a process you expect to keep, so the honest comparison is against the cost of the workaround: hours of manual work, errors and decisions made on old numbers. We do not publish price ranges, since they would be meaningless without a scope. The guide to software development costs in Denmark explains what drives the budget, and the article on custom software versus SaaS helps you decide whether to build at all. If a standard product would solve the problem, we will recommend it.

Questions and answers

When should a company choose custom software instead of SaaS?

When the process is specific to the company, when several tools are held together by manual copying, or when a standard product forces the team to work around it every day. For generic tasks such as accounting, a standard product is usually better.

Can a custom system work together with the software we already have?

Yes. Most projects include integrations. The new system handles the process that is missing and exchanges data with existing tools through their APIs, so nothing has to be replaced unnecessarily.

How small can a first version be?

As small as the part of the process that causes the most manual work. A first release with one workflow, the right roles and a clean data model is more valuable than a large system that arrives late.

What happens to our existing data?

Existing spreadsheets and databases are reviewed during the scope phase and imported before launch. Cleaning inconsistent data is often part of the work, and it is included in the scope so it does not come as a surprise.

Can you modernise a system that was built years ago?

Yes. UnderStack is modernising the Peritar platform for ASEPCO from legacy PHP to TypeScript, with a new interface and a maintainable code structure, while the platform remains in use.

How do we get a quote?

Write a short message describing the process, the people involved and the tools in use today. After a short clarification you receive a written scope and a quote for the first release.