Custom software in Switzerland.

Custom software is written for one client and encodes that client’s workflows; off-the-shelf software is sold as a product to many customers, who adapt to its logic. That is the whole difference — and it has less to do with technology than with the question of who adapts to whom.

What it does not mean is "build everything yourself". No serious project today writes user management, payment processing, mapping or document storage from scratch. Custom software means the core that makes your business distinctive is written for you, and everything else is brought in through proven components and services. A project where 80 per cent of the code is your own domain logic has usually been scoped wrongly.

In practice we meet three variants. First, full bespoke development, which makes sense for workflows no market exists for. Second — the most common and usually the most economical case — a standard product as the backbone, extended with custom-built parts where things are genuinely your own: a customer portal in front of the ERP, an interface between two systems, a configurator that produces quotes. Third, replacing a grown spreadsheet landscape in which a company’s knowledge lives in files with version numbers in their names.

Technically, custom software with us almost always means a web application: it runs in the browser, needs no installation, works on laptop and mobile, and can be updated centrally. What that means for your users and where the limits are compared with a native app is covered on web app development.

Custom software pays off when the cost of the detours around a standard product is greater than the cost of building your own — calculated over four to five years, not over the first year. That calculation favours bespoke development less often than agencies like to claim, and considerably more often than software vendors admit.

Four signals argue reliably for building your own:

• The workflow is the reason customers buy from you. A proprietary assessment method, a distinctive onboarding, a way of pricing nobody else uses — what sets you apart should not be squeezed into a third-party comments field.
• The workarounds are growing. Parallel spreadsheets, copies in secondary systems, one person reconciling by hand: these are running costs that appear on no software invoice but arrive every month.
• Licence costs scale with headcount. With per-seat pricing the standard product grows as the team grows; bespoke software does not. Above a certain number of users the calculation flips.
• The data is the asset. If your data holdings have value in themselves, questions of storage location, exportability and access are not side issues.

Three signals argue just as clearly against: your process matches the standard and works; the number of users is small and will stay small; or a mature industry solution already exists whose feature set you would not match in your own project for years. In those cases we say so in the first conversation, even when it argues against the engagement.

A common mistake is comparing "purchase price against subscription price". Put two five-year totals side by side instead: on one side licences, roll-out, adjustments, interfaces and the working time spent on detours; on the other development, operations, maintenance and further development. Only that comparison is a basis for a decision. For a first sense of scale for your venture, our project calculator helps; the full price ranges are on software costs in Switzerland.

A project with us runs in five stages — requirements, prototype, first production version, expansion, operations — and after each stage you can stop without losing what you have already paid for. Those exit points matter more to us than a tidy project plan, because they cap your risk.

1. Requirements. We sit down with the people who will use the software daily, not only with management. The output is not an 80-page specification but an ordered list of workflows, a rough data model, and an honest split between "must exist at launch" and "can come later". That split decides more about the budget than any technology choice.

2. Prototype. Before the domain logic gets built, a usable version of the most important screens appears. It has no complete database behind it yet, but it is real enough to expose misunderstandings. If you want to keep the entry even narrower, prototype and idea validation is the cheaper route — it starts at CHF 10,000.

3. First production version. The smallest scope with which real work can be done: sign-in and roles, the data model, the main workflow, one interface. From here the software is in use and produces feedback from real operations — the only source that reliably shows what is actually missing next.

4. Expansion in cycles. Two- to three-week cycles at a fixed capacity, a working version at the end of each cycle, and prioritisation done together. You pay for capacity and decide continuously what it is spent on.

5. Operations. Monitoring, backups, updates, support — the part rarely discussed before a contract is signed, and the part that decides how long the software lives.

What that looks like in practice is shown by one of our own projects: a web app for tax returns in the Zurich area, where clients choose a package, create a sign-in, upload documents and book their appointment online. That is custom software in the sense described here — a workflow no standard product handles in that form. Further projects are in our work.

In Switzerland the rights to software developed under contract do not pass to the client automatically — not even when the whole project has been paid for and the source code handed over. This is where most later conflicts start, and the reason we put it on paper before the contract is signed.

The legal position in short: copyright arises with the natural persons who created the work. Art. 17 of the Swiss Copyright Act assigns the exclusive powers of use in computer programs to the employer — but expressly only for programs created in an employment relationship in the course of official duties. A contract for services between you and an agency is not an employment relationship. And Art. 16 para. 3 states that transferring a right in a copy of a work does not include the copyright in it: you can hold the complete source code in your hand and still not be entitled to have it modified or passed on.

The consequence is uncomfortable but simple: without an express clause in the contract you remain dependent on one supplier. So check five points before signing — with any agency, not only with us:

• Transfer of rights. Are the rights of use in the code written specifically for you transferred expressly and exclusively, including the right to modify, and without being tied to an ongoing contract? A mere "right of use" without the right to modify bars you from having third parties develop it further.
• Timing. Do the rights pass on acceptance or only on final payment? Either is permissible, but it has to be written down.
• Repository and credentials. Do the code repository, database, hosting, domain and certificates run on your accounts? If the agency owns those accounts, the finest rights clause is of little use to you.
• Third-party components. Which open-source libraries are built in, and under which licences? Copyleft licences can restrict how you later commercialise the result. A dependency list with licence details belongs in the delivery.
• Reused building blocks. Almost every agency brings pre-existing components of its own. Those are usually licensed to you rather than transferred. That is legitimate — it simply has to be named, so you know which part is yours and which is not.

Our rule: the code written for you belongs to you, with the right to modify it, with no tie to a maintenance contract. Repository, database and hosting run on your accounts from day one, with us as invited collaborators. Reused components of our own are named and licensed to you indefinitely. If one day you no longer need us, you should be able to leave — that is not a concession but the precondition for you keeping us voluntarily.

The price of custom software comes almost entirely from the scope at launch, not from the technology — and the scope at launch is the one variable you control yourself. That is why we deliberately quote no figure for a full project before the requirements work: any number without a clarified scope is guesswork, and guessed numbers are the most common cause of arguments in month three.

What we can state bindingly in advance is the entry point. A prototype for validating an idea starts at CHF 10,000. It is deliberately cut so that it tests the riskiest assumption in your venture — nothing more. A conventional website with no domain logic of its own sits between CHF 3,000 and CHF 25,000 with us; the boundary is drawn on web design prices, and the broader market ranges on software costs in Switzerland.

These six factors drive the effort in almost every project, in descending order of impact:

• Roles and permissions. An application where everyone may do everything is a fraction of the work compared with one that has five roles, approval stages and an audit trail of who changed what and when.
• Interfaces to existing systems. Every connection to ERP, accounting, warehouse or point of sale is its own small project — with someone else’s documentation, someone else’s error messages and someone else’s maintenance windows.
• Data migration. Legacy data is rarely as clean as it looks in the meeting. Cleaning, mapping and test runs take more time than almost any client plans for.
• Edge cases. The main workflow is built quickly. Discounts, cancellations, partial payments, returns and the exceptions "we just handle by hand" cost the larger share.
• Legal requirements. Personal data, audit logging, retention periods and deletion policies under the revised Data Protection Act are effort that never becomes visible on screen but still arises.
• Design. A functional interface following clear patterns is cheap. A bespoke visual system with animation and polish is a deliberate additional decision, not a given.

If your budget is fixed, we invert the calculation: instead of asking what the desired system costs, we define which scope is productively usable within your budget. That almost always produces a better first version than the other way round.

Custom software is not finished at go-live, it is in operation — and software nobody maintains becomes a security risk within two to three years and barely changeable within five. Maintenance is therefore not an upsell but part of the investment decision.

Maintenance covers four technically distinct things. Security and currency: libraries and runtimes are updated continuously; skip a year and catching up is not a small step but a rebuild. Operations: monitoring, backups with tested recovery, certificates, availability. Corrections: faults that only appear in real use. Further development: new requirements from the business — the only one of the four that is optional.

We bill maintenance by actual effort or through a monthly hour allowance you split freely between upkeep and further development. For budgeting, the industry rule of thumb of roughly 15 to 20 per cent of the original development cost per year is a workable order of magnitude; with many interfaces it runs higher, with a self-contained internal application lower.

One point that is rarely raised: choosing not to develop further is a legitimate decision too. Some applications are finished after the first version and should simply run reliably for ten years. Maintenance then reduces to security and operations — and that is exactly what belongs in the contract, rather than being billed through a package nobody uses.

Custom software is the wrong decision in more cases than the right one, and the following five situations are the most common. We name them in the first conversation, because a project that starts for the wrong reasons ends expensively for both sides.

• Your process is standard. Accounting, payroll, time tracking, newsletters, appointment booking with no special rules: mature Swiss products exist for all of these, and you should adapt to them rather than the reverse. Building your own would be more expensive and worse.
• You want to rebuild a standard product one to one. Anyone setting out to rebuild an industry solution with ten years of development behind it systematically underestimates its feature set — only the surface is ever visible.
• The process is not settled internally. When three departments describe differently how an order moves through the company, the software decides the question — badly. Settle it first, then build.
• Nobody owns the application. Custom software needs an accountable person on your side with decision-making authority and time. Without them the project drifts between cycles.
• There is no budget for operations. If development consumes the entire budget and nothing is left for maintenance, the investment is lost within two years. A subscription is then the more sensible choice.

Equally honest: we are a small digital agency with our own development team, not a systems integrator. For ventures that reach deep into an existing ERP, require certified industry standards, or occupy a team of twenty developers for two years, we are not the right partner — and we would rather say so at the start than in month four. Where we are strong is the layer in front: between your customers and your systems, in clearly bounded applications, portals and automations. If you are at the very beginning and want to test the idea first, our start-up consulting is a better entry point than a development contract.