localhost.co.rs

Do you need a developer every time a form changes?

A delivery charge, a deadline, an email template or an approval limit shouldn't wait for a developer. What the business should change itself, and what not.

3 min read

Abstract drawing of a control panel with sliders and switches, most switched on and one switched off

The delivery charge changes. Or the amount above which purchasing needs the director’s sign-off. Or the wording of the email a customer receives after ordering. A small thing. Yet in many businesses it is a small thing that waits a week, because a developer or the software vendor has to do it, with a fresh invoice attached.

Once that happens often enough, people stop asking for changes. The business rules stay exactly as they were when the software was built, while the real work keeps changing alongside it.

Business rules and system construction are not the same thing

Every business application has two layers, even if nobody ever called them that.

The first layer is the rules: values the business decides. Prices, limits, deadlines, wording, pick lists, who approves what and who gets notified.

The second layer is the construction: how data is stored, how amounts that must be exact are calculated, how the system talks to other systems, and who is allowed to see what.

People in the business should be able to change the first layer. Not the second — not because they aren’t capable, but because a mistake there doesn’t show immediately, and by the time it does, the damage is done.

What you should be able to change yourself

  • amounts, percentages, limits and deadlines
  • code lists and pick lists: complaint types, cancellation reasons, regions
  • the wording of messages and notifications, and document templates
  • who receives which notification and who approves what
  • which fields are mandatory, as long as that doesn’t break other parts of the work
  • reports: which columns, which filters, which order

If anything on this list requires a call to a developer, the system was built in the way that was easier for them and more expensive for you.

What shouldn’t change without someone who knows the consequences

  • tax, invoice and payroll calculations
  • links to other systems: accounting, the e-invoicing system, the bank, the warehouse
  • access rights to data
  • deleting and merging records

Here a call to the developer is justified. Even then the change should be quick and clear, because the system has to be built so that a change in one place doesn’t ripple into ten others.

Why systems often don’t allow even the first kind

Because it was quicker to build that way. When a rule is written straight into the code, the software is finished sooner. The price is paid later, with every change.

You won’t see this in a demo, because a demo shows how the software works today, not how it changes tomorrow. So ask the question before you sign, and get the answer in writing.

When no-code tools are perfectly adequate

To be fair: plenty of work needs no purpose-designed system at all. Internal forms, simple approvals, records for a small team, a quick test of an idea — no-code tools do these well, set up quickly, and people in the business really can change them themselves. If that is all you need, we will tell you.

When a system designed for your business pays off

  • when it is the core of the business, with rules that are complex and entirely your own
  • when volumes are high, so speed and reliability become a question of money
  • when you need links to accounting, e-invoicing or the warehouse that must work without errors
  • when an app in a no-code tool was built by one enthusiast, has become indispensable, and nobody else knows how it works
  • when per-user licences grow faster than the company

Even then the same principle holds: settings belong to the business, construction to the developers.

Four questions before you sign

  1. What exactly can I change myself, without a phone call and without an invoice?
  2. Can I see who changed what and when, and can it be rolled back?
  3. Can a change be tried out before it applies to everyone?
  4. How much does a change I can’t make myself cost, and how long does it take?

When we design and build a system, we agree at the outset which rules stay in your hands as settings. There is more on our CRM and ERP systems page. If every small change currently means a new invoice, get in touch.