Simply

Most ATSs have a table for candidates, a table for jobs, and a new table with a migration for every new wish. Simply doesn't. All records live in one generic store in PostgreSQL: the values as JSON, and the fields you sort or filter on projected next to them as typed columns, so long lists stay fast. Relations between records are separate links, not fixed references inside a table.

As a user you notice it mostly in what you no longer have to do. Adding a field takes no release and no database migration on your existing records. A whole new object, say 'Assignments' or 'Events', gets a list view, a detail page, permissions and an API endpoint right away, because the runtime doesn't know and doesn't need to know that it isn't a candidate. The ATS itself ships the same way: as a template of objects, fields and pipelines on top of the platform.

Architecturally it's a modular monolith with strict layering. The domain knows the rules, the application layer the use cases, the infrastructure layer the database and outside services, and the API layer only translates HTTP into a single use case. None of that lives in a wiki. A separate test suite checks on every build that no layer depends on another in the wrong direction, and the build fails if one does.

In a lot of software, AI is a button that returns text. Here it sits in three places in the system itself: in writing, in retrieval and in automation. Writing follows the rule the whole product rests on. A model is never allowed straight into the database; it files a proposal, which goes past the same permission check as a user's own action and only runs after approval. Proposal and approval end up together in the audit log.

Retrieval works on a memory layer that's fenced off per workspace. Conversations, messages and documents are turned into embeddings and searched with pgvector, after which the result is filtered down to what the person asking may see. If you have no access to a salary field, you won't get it through a detour via the agent either. Sources stay traceable, and what has to go under the GDPR goes from that memory too.

A few parts run without an outside model on purpose. The classifier that reads the intent of an inbound message runs inside the application's own process, and so does cutting the headshot out of a CV. No personal data leaves for a task that doesn't need it to.

For the tasks that do need a language model, the provider is swappable. Agencies use Simply's key or bring their own key and model; in that case they pay their AI usage straight to the provider.

The platform and the database run on servers in the Netherlands that the team manages itself, and by default the AI processing goes through data centres in the EU as well. For an agency holding data on thousands of candidates that's no detail from the small print. It's often the first thing procurement asks.

Separation between customers runs deep. Every row in the database belongs to one workspace and authorisation is always checked inside that workspace, so one agency's data can't end up with another. Personal data is encrypted, traffic runs over TLS, and every write goes into an audit log that only ever grows. Not even an administrator takes a line out.

Around the application runs a handful of services with one job each. PostgreSQL with pgvector holds the data and the search index; a workflow engine watches long-running processes and carries on where it was after an outage; a render service produces the PDFs and an observability layer measures the cost and duration of every AI call. The admin screens of those services aren't on the public internet and can only be reached over a private network. Releases go through a test environment as container images first, and backups run daily.

Simply is ISO 27001 certified, and that certificate covers the organisation and not just the software: documented processes, access management, risk analysis and a check by an independent auditor every year.

Choosing a new ATS is one thing; switching while the business keeps running is where it usually falls apart. That's why the move was designed as a process and not as an import button. In week one the migration team maps the existing data model, the workflows and the integrations, and a first export comes in. After that the team sets up the new environment, an admin from the agency checks that everything is right, and the agency only goes live on a fresh export.

Because the data model is made of metadata, the old system's data doesn't have to squeeze into a fixed shape: the model is formed around the agency. Simply deliberately doesn't sync with another ATS. You move once, and after that you don't keep two systems side by side.

A system this size breaks through sloppiness, rarely through one big mistake. So a few hard rules apply. Compiler warnings count as errors, and integration tests run against a real PostgreSQL database, not a simulated one. Every error also carries a fixed code, so support and developers are talking about the same thing.

The team doesn't maintain documentation by hand. A pipeline generates the technical documentation from the code itself and rebuilds it on every change, which means what's written matches what's running. That same documentation is searchable for the AI agents the team uses while developing.

Those agents do real work. One reads every pull request and is handed exactly the design documents that belong to the changed files; another picks up bug tickets, writes a fix and submits it as a pull request, under the same tests as a person. A developer decides on every merge. It's how we build for TopDevs clients too: AI does the executing, people keep the design and the final call.

The application's design wasn't bought in. Every screen started as a mockup in real HTML, so we could click through a flow before a single endpoint existed for it, and then moved into a design system where each part exists only once. That's why an object a customer created yesterday looks as cared for as the candidate list.

The same goes for everything around it. The brand, the website with its moving product demos, the comparison pages and the knowledge base were made by the same people, and so were the videos: the Simply Ask film, the product film and the founder story never left the building between script, motion design, edit and sound. It saves handovers, and it keeps what marketing promises in line with what the product does.

Simply isn't a project we delivered once and then let go of. The three owners of TopDevs set the company up and led the project from the first sketch, and the team that builds and runs this platform is the team you sit down with at TopDevs. There is no second agency in between: design, architecture, code, servers, website and video come from the same hands. That's why we know what it's like to run software a business depends on: every day, with thousands of users, in several countries and under an ISO certification.

What that means for your project is concrete. The choices in this case aren't theory from a proposal: a data model that grows with you, AI that proposes and doesn't overwrite, hosting we run ourselves, and tests that guard the architecture. They're things we maintain ourselves every week. When we recommend an architecture, chances are we already have it in production.