Custom web platforms, engineered to be operated for years
Saffron Systems designs and builds custom web applications for businesses whose work has outgrown spreadsheets, a stack of disconnected subscriptions, or a marketing website: client portals, operations consoles, booking and intake systems, internal tools and data-backed products. You own the source code, the infrastructure and the runbook from the first day.
- Division
- Saffron Systems, the software and application engineering division of Saffron
- Based
- Minneapolis, Minnesota. Work is delivered remotely.
- Engagement
- Agreed after discovery: a fixed price for a defined scope, or a time-based rate for open-ended work
- You own
- Source, infrastructure, credentials and documentation
What a web platform is, and what it is not
A web platform is software that people sign in to in order to get work done: staff processing cases, clients checking the status of an order, a manager approving a schedule. It holds real data, enforces who may see and change what, connects to the other systems a business already runs, and keeps working when the person who built it is not around.
It is different from a marketing website, which exists to be found and to persuade. That is the work of Saffron Designs. It is also different from a single automation that moves data between two tools on a schedule, which is the work of Saffron Automations. When a project needs more than one of these, the divisions split the work explicitly rather than each selling the whole.
Who this is for
- A workflow that costs staff hours every week or produces errors, and no off-the-shelf product fits it without contortion.
- Several subscriptions held together by copying and pasting between them.
- Clients or partners who need a secure place to see their own records, documents or status.
- An existing application that works but that nobody can safely change any more.
- A brochure site or landing page. Start with Saffron Designs.
- One integration between two tools. Start with Saffron Automations.
- A commodity function that a mature product already does well, such as accounting or payroll. Buy it.
- A fixed feature list that must ship without anyone looking at how the work is actually done.
What Saffron Systems builds
Most platforms are assembled from the same small set of parts. The engineering is in getting each one right for the business in front of us:
- Identity and roles. Sign-in, sessions, and a permission model that says who may read, change or approve each kind of record.
- The data model. A relational database, usually PostgreSQL, designed from the records the business actually keeps, with constraints that make bad data impossible rather than merely discouraged.
- Typed interfaces. APIs whose inputs and outputs are validated at the boundary, so a malformed request is refused with a clear error instead of corrupting data.
- The console. The screens staff use every day, designed around the tasks they repeat most.
- Integrations. Payments, email, calendars, CRMs and accounting systems, connected through their official APIs, with retries and a record of every call that failed.
- Background work. Scheduled jobs, queues and notifications, each observable and safe to run twice.
- An audit trail. Who changed what, and when, for every record that matters.
How architecture decisions are made
Architecture starts from the data and from the ways the system can fail, not from a preferred framework. For each significant choice, such as which database, where the application runs, or whether to build or buy a component, Saffron writes a short decision record: the options considered, the one chosen, and the reason. The record stays in your repository, so the next engineer can see why the system is the way it is.
The default is well-understood technology with a long support horizon. Novel tools are used when they solve a problem the ordinary ones cannot, and the decision record says so. Saffron's own properties run on managed serverless hosting with PostgreSQL, which keeps operating costs proportional to use; a platform with different needs, such as long-running processes or data that must stay in a particular region, is designed for those needs instead.
Security, resilience and the rest of the non-negotiables
| Concern | How it is handled |
|---|---|
| Security | Least-privilege access for people and services, secrets kept out of source code, input validated at every boundary, dependencies kept current. Requirements are checked against the OWASP Application Security Verification Standard at the level agreed for the project. |
| Resilience | Timeouts and retries with backoff on every external call, idempotent jobs, backups that are restored in a test before launch, not just taken. |
| Observability | Structured logs, error reporting and health checks from the first deploy, so a failure is visible to you before a customer reports it. |
| Accessibility | WCAG 2.2 level AA is a delivery acceptance requirement, verified before handoff, including keyboard-only use and screen readers. |
| Performance | Lighthouse 95 or higher is a delivery acceptance requirement, verified before handoff. Pages are also measured against Google's Core Web Vitals on a mobile profile before launch. |
| Rollback | Every release is an immutable build that can be restored in minutes. Database changes are written so that the previous version keeps working while they roll out. |
| Release evidence | Each release can carry a signed attestation of exactly what shipped, as described in How a Saffron release is proven. |
How a build runs, from first call to handoff
- Discovery. We sit with the people who do the work, map the workflow as it really happens, and list the data, the integrations and the risks. You receive a written summary.
- Blueprint. A specification with acceptance criteria, an architecture, the first decision records, and the price and schedule for the scope agreed.
- Build in increments. Working software on a staging environment early and often, so you judge real screens, not mock-ups.
- Verify. Automated tests, security and performance checks, and review on real devices, with the evidence kept.
- Launch. Released with a rollback path ready and monitoring watching from the first minute.
- Handoff. Access, credentials and a runbook transferred to you, written so that any competent engineer can operate and extend the system.
What you own
- The source code, in your own repository, from the first commit.
- The hosting, database and third-party accounts, in your name and on your billing.
- The credentials, stored in your password manager, not ours.
- The documentation: decision records, runbook, and how to deploy and roll back.
- Reusable Saffron components, under a permanent licence to use them.
- No proprietary runtime or licence that makes you depend on Saffron to keep the system alive.
What Saffron can show you today
Client platforms are private, and Saffron does not publish a client's system or results without the client's written permission. Case studies will appear here as clients approve them. What is public today, and exactly what each item demonstrates:
| Evidence | What it demonstrates | What it does not |
|---|---|---|
| Signed release attestations on this site | The release discipline described above is real and running: you can verify a published attestation yourself. | It says nothing about the business logic of any client system. |
| The Web Vitals Ledger and its live page | How Saffron measures page performance: one configuration, four runs, the worst run published, raw data included. | It measures studio websites, including Saffron's own, not client platforms. |
| saffron-quality-gate, installable from PyPI | Saffron's engineering standard is written down as a runnable command-line check, not only as a promise. | A pattern scanner cannot prove a codebase is correct. It flags known failure patterns. |
| The scheduling system on saffrondesigns.io | A live booking platform built and operated by Saffron: real availability, holds and confirmations. | It is Saffron's own system, not a client deployment. |
Tradeoffs worth knowing before you build
- Build or buy. Build where the workflow is how you compete or where no product fits. Buy where the function is a commodity. Many good platforms do both: custom where it matters, connected to bought software everywhere else.
- Ownership has a running cost. Hosting, security updates and small changes continue after launch. The blueprint states the expected monthly operating cost so it is not a surprise.
- Scope grows unless it is managed. Fixed scope protects both sides. New ideas go on a list for the next phase rather than into the current one.
- Knowledge must not live in one head. Tests, decision records and the runbook exist so that the system survives any single person, including us.
- Low-code platforms trade speed for lock-in. They can be the right answer for internal tools with a short life. They are rarely the right foundation for a system the business will depend on for years.
Questions buyers ask
How long does a custom web platform take to build?
It depends on the scope, the number of integrations and how quickly decisions can be made on your side. Saffron gives a dated schedule for the agreed scope at the end of discovery, not before, because an estimate made without discovery is a guess.
How much does it cost?
Saffron Systems agrees the price after discovery and writes it into the blueprint: a fixed price for a defined scope, or a time-based rate for open-ended work. The blueprint also states the expected monthly cost of running the platform.
Do we own the code?
Yes. The source lives in your repository from the first commit, and the hosting and third-party accounts are in your name.
Can you take over an application someone else built?
Often, yes. The work starts with a written assessment of the codebase, its tests, its deployment and its risks, so that you know what you have before anyone changes it.
Should this be a web application or a mobile app?
If most use happens at a desk, or the users are your own staff, a web platform is usually faster to build and easier to change. If the product depends on the phone itself, such as offline use in the field, the camera, or push notifications, a native or installable app may be right. Discovery answers this with your actual users.
What technology do you use?
It is chosen per project and recorded with the reason. Saffron's own properties run on managed serverless hosting with PostgreSQL. Where you already have a stack and a team that knows it, the platform is usually built to fit it.
Describe the work you want the platform to do
Write with the workflow you want to replace or the system you want to build: who uses it, what data it holds, and what it has to connect to. The reply will be questions about the work, followed by a proposal for discovery.