Custom software development, built around how you work

When does custom software make sense?

Custom software pays off when the way you work is part of what makes you competitive, or when standard tools force workarounds that cost more every year than building would. It is usually the wrong call when an off-the-shelf product covers most of the process and the rest can be handled by configuration or a small integration. We check this honestly at the start, because the cheapest software is the software you don’t have to build.

Signals we look for: a process that runs through spreadsheets and email because no tool fits it; staff re-typing the same data into several systems; per-user licenses paid for people who only need one screen; data that has to stay under your control. The trade-offs are laid out in custom vs off-the-shelf software.

How we build custom software

Discovery with the people who do the work. We map the process as it runs today, exceptions included, and write business rules as testable statements (“an order above the credit limit needs a manager’s approval”) rather than descriptions of screens. The output is a data model, an architecture note and a first release that is useful on its own.

Plain, proven architecture. Most business systems we build are one application with a PostgreSQL database, a typed REST API documented with OpenAPI, and a React or server-rendered interface. We split out separate services only where load, isolation or an independent release cycle justifies it. Backends are Python (FastAPI, SQLAlchemy, Alembic migrations) or Node.js with TypeScript, chosen to fit your team and existing systems.

Tests from the first week. Unit and integration tests run in CI on every change, with Playwright end-to-end tests on the critical flows, and deployments are gated on a passing suite. The first instance of the outreach platform we built for a SaaS client shipped with about 160 automated tests.

Security as the default. Roles are enforced in the backend, passwords are hashed and logins lock after repeated failures, and secrets stay out of the code. Admin dashboards refuse to start on a public address until authentication is configured. Where the server fetches external URLs, it only connects to public addresses and re-checks them after every redirect, which closes the usual SSRF holes.

Operations planned before launch. Docker images, a staging environment, a reverse proxy with TLS, structured logs, backups and a runbook that someone other than the original developer can follow.

What goes wrong in custom software projects

• Rules discovered during user testing. When scope is described as screens, edge cases surface late. Writing rules as tests and as settings (thresholds, time windows, priorities) keeps them visible and changeable without a release.
• Integrations underestimated. External APIs have rate limits, missing fields and undocumented behavior. We connect to every external system in the first sprint, and integrations stay read-only unless writing is required. In one system we built, the integration can only call an allow-list of read operations, and a test proves that a full import makes no write calls.
• Jobs that run twice. A retried job sends the same email or creates the same order a second time. Unique keys, atomic claims and idempotent handlers make re-runs safe.
• No owner after launch. Software nobody understands decays quickly. You get documentation, a runbook and the option of ongoing development with Sensaria.

What drives cost and timeline

Driver	Effect on effort
Workflows and user roles	Each role and approval path adds screens, rules and tests.
Integrations	The quality and limits of external APIs often decide the schedule.
Data migration	Cleaning and moving existing data is routinely underestimated.
Audit and compliance	Logs, retention rules and access controls add design and testing work.
Interface complexity	Bulk editing, complex tables or offline use cost more than simple forms.
Availability	Round-the-clock operation needs monitoring, redundancy and on-call cover.

We quote a fixed price for a clearly defined first release, or work in phases when discovery shows that parts of the scope depend on how people use the first version. Either way you see the plan and its assumptions before work starts.

Data protection and hosting

Business systems usually hold personal data, so data protection law shapes the design: the revised Swiss Federal Act on Data Protection (FADP), in force since 1 September 2023, for data processed in Switzerland, and the GDPR for people in the EU. Under the FADP, Article 7 requires data protection by design and by default. Article 16 allows disclosure abroad only to countries with adequate protection or under additional safeguards. Article 24 requires reporting to the FDPIC any breach likely to result in a high risk for the people concerned. In practice we build roles, retention rules and audit logs into the first release, document which processors see which data, and host in Switzerland or in an EU region depending on your contracts and sector.

How it connects to the rest of your systems

Custom software rarely stands alone. It reads from and writes to your CRM, accounting or e-commerce platform through API integrations, sometimes grows into a custom CRM or ERP, and occasionally becomes a product for other companies through SaaS development. Typical scenarios are described under internal business systems.

Why Sensaria

Sensaria AG is a Swiss company based in Lugano. For a SaaS client we built a startup discovery and outreach platform: a daily pipeline with approval queues, a role-based dashboard and hand-off to the client’s CRM. We also built an affiliate reactivation system that analyzes a third-party platform strictly read-only, and an affiliate recruitment engine with SSRF-safe crawling and an audit trail for every merged identity. We work in English, Italian, German and French.