--- title: "Standard Software Is One Vendor's Way of Working. Custom Software Is Affordable Again." description: "Why the standard in standard software is a vendor's design, what customising it costs at every new release, and how to tell which part of your work is worth building as your own." date: 2026-11-10 author: "David Wippel" tags: ["agency", "ai"] url: https://www.essentialcode.eu/blog/standard-software-is-one-vendors-way/ --- # Standard Software Is One Vendor's Way of Working. Custom Software Is Affordable Again. > Why the standard in standard software is a vendor's design, what customising it costs at every new release, and how to tell which part of your work is worth building as your own. **TL;DR.** The standard in standard software is the way one vendor decided the work should run. Where your company works differently, every customisation has to be carried through each new release. AI agents directed by senior engineers now make software of your own affordable for small and mid-sized companies, so the part that never fit can be built for how you work. Your company runs on standard software. An ERP, a CRM or the one industry package your niche offers. Most of it works. Then there is the part where your team keeps a spreadsheet beside the system, enters the same thing in two places, or follows a workaround that one person explains to every new colleague. The usual answer is to customise the standard software until it fits. I think that answer is changing. Software built for your company is affordable again, and for the part that never fit, it is now the option worth pricing first. ## What is the "standard" in standard software? A real standard is written by a standards body and anyone can build to it. The European standard for electronic invoices is one. The European Commission's eInvoicing pages put it this way: "The European standard on eInvoicing (EN 16931) was developed and published by the European Committee for Standardization (CEN), at the request of the European Commission." Every invoicing tool can follow it, and ours does. That is what the word standard means outside software: one set of rules, written by a body that sells no software. The "standard" in standard software is something else. It is the way one vendor decided a piece of work should run, built into its screens, its documents and its data. Take an overdue invoice. ERPNext's documentation describes its answer like this: "A Dunning turns that overdue balance into a traceable collection document." A dunning is a formal payment reminder. That is a sensible design, and it is ERPNext's design. Another vendor makes its own choices for the same step, and your company may handle overdue customers in a third way that works well for you. None of this is a problem while your work runs the way the vendor imagined. It becomes one in the part where it does not. ## What does customising standard software cost you over time? Changing standard software to fit is a one-time cost on the day you do it. Carrying the change is a cost every time the vendor releases a new version, because your change has to keep working on top of a product that keeps moving. The vendors say so in their own documentation. | Vendor | What its own documentation says | What it means for your customisation | | --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | Odoo | "If your database contains custom modules, it cannot be upgraded until a version of your custom modules is available for the target version of Odoo." | Every upgrade waits until your custom modules are ready for it. | | Odoo | "If a change introduced by a new version breaks a customization, it is the responsibility of the maintainer of your custom module to make it compatible with the new version of Odoo." | When a new version breaks a customisation, somebody in your team or outside it has to make it work again. | | Microsoft Dynamics 365 finance and operations | "Service updates are released only in February (December self-update), April, July, and October." | Four new versions a year, and you take at least two of them. | | Microsoft Dynamics 365 finance and operations | "The maximum number of consecutive updates that can be paused is reduced from three to one." | You can wait out one update. You cannot wait out the next one. | This is how the vendors keep their products current, and for the standard part of your work it is a good deal: you get new versions without doing anything. For the customised part, the vendor's release schedule becomes your maintenance schedule. ## Why was custom software out of reach for so long? Software written for one company used to need a team and a budget that only large companies had. Somebody had to research how the company works, write the specification, build it, test it and keep it running. For a small or mid-sized company, or a niche industry, the numbers rarely worked. So the standard package won by default, and the customisation bill came later. ## What changed? AI agents now do much of that work: the research into your industry, the specification, the code and the tests. Senior engineers direct the agents, decide what the software has to do and check every result before it goes live. The check is part of the work, because fast software that is wrong is worth nothing to a company that runs on it. We tested this on ourselves. We needed an invoicing system with Austrian invoicing rules, recurring invoices, real custom layouts and documents in several languages, and none of the tools we tried combined all of it. We wrote the brief, and about three days later the system ran on our test site. Six months ago I could not have offered software built like this for a budget a small company can carry. ## Where does standard software still fit? Standard software is a good choice for every part of your work that runs the standard way. If your accounting follows the usual rules and your team is happy with the screens, keep it. Building your own version of something that already fits would be money spent for nothing. The question is only about the part that never fit. For that part there are now two options worth comparing: - **Customise the standard software,** and carry the customisation through every new version. - **Build that part as software of your own,** beside the standard software and connected to it, or in place of that one part. A connection to standard software has to survive its new versions too. The difference is size: a connection that reads and writes data through the interface the vendor publishes for other systems is usually a much smaller thing to keep working than changes made inside the product, and the people who built it are the ones who keep it running. ## How do you tell which part to build? Look for the places where your team works around the system instead of with it: - A spreadsheet that lives beside the system and that one person understands - The same information entered by hand in two places - An upgrade that keeps moving to next year because nobody knows what it will break - A rule from your business that the system cannot hold, so people remember it instead - Screens your team avoids because they take longer than doing it on paper If one of these costs you time every week, write down how that work should run. That description is most of what a team needs to start building it. It also helps to have one person who can decide how the software should work, because a build moves as fast as its decisions are made. ## What it looks like when we build it We build that part with you as [Agentic Custom Software Development](/services/web-app-and-saas-development/): senior engineers who learn how your company works, direct the AI agents that build the software, and keep it running after launch. The code and every account are in your name from the first day, and the work runs month to month.