Sample report
Architecture review: Tidsplan ApS (sample)
This is a sample. The company, the people and the numbers are made up. It shows the shape of an architecture review: the business first, then what is solid, what is risky, and what to change first.
Tidsplan makes job planning software for plumbers and electricians in Denmark: a web app for the office and a mobile app for the people on site. Six engineers, about 120 customer companies, a Java backend (Spring Boot) on PostgreSQL, in one cloud region in the EU.
1. What the business needs next
Agreed with the founders and the head of product before I looked at the code. Everything below is measured against these.
- Five times the customers in 18 months, and about ten times the jobs planned per day, mostly from Sweden.
- Swedish customers: Swedish language and VAT, and customer data that stays in the EU.
- Accounting integrations: jobs flow into the customers' accounting systems without anyone typing them twice.
- Work on site without a signal: basements and new buildings often have none, and changes made offline must not be lost.
- Ship several times a week, without downtime. Today releases happen on Friday evenings, with the app down for about 15 minutes.
- A technical due diligence for the next funding round, in about a year.
- AI coding agents for the team, safely.
2. What is solid
- One codebase with clear modules. Planning, billing and customers live in separate packages with few calls between them. That is a good place to grow from; it does not need to become many services.
- PostgreSQL is the right database for this business and will carry the planned growth.
- Billing is well tested, and the team trusts its tests there.
- The team knows the system. Two of the first engineers are still here.
3. What is risky
Ordered by how much it threatens the plan in section 1.
- A
Mobile sync overwrites whole jobs: the last device to sync wins
Offline changes get lost today, and it gets worse with more people on site.
Needs: 1, 4
- B
Accounting integrations run inside web requests
A slow accounting system makes the app slow for everyone, and a failed call loses the update.
Needs: 1, 3
- C
The planning calendar reads one large jobs table without the right indexes
The calendar takes about 2 seconds at peak today; at ten times the jobs it stops being usable.
Needs: 1
- D
Releases need downtime
Fine with 120 customers, not with 600 across two countries.
Needs: 1, 5
- E
Passwords and keys sit in configuration files in the repository
A risk now, and a blocker before AI coding agents get access and before due diligence.
Needs: 6, 7
- F
Deleting a customer's data takes manual SQL
GDPR requests will grow with the customers, and reviewers will ask.
Needs: 2, 6
4. What to change first
With the trade-offs and a rough effort for each. Efforts are for this team of six.
Secrets out of the repository, and rules for AI coding agents (risk E)
A secrets store, keys rotated, a rules file for agents and review of their changes.
Indexes and per-company queries for the calendar (risk C)
Integrations through a job queue (risk B)
An outbox table in PostgreSQL and a worker that retries.
Releases without downtime (risk D)
Two app instances behind the load balancer, and database changes that work with both the old and the new version.
Sync by change, not by whole job (risk A)
The phone sends what changed, field by field, and the server keeps those changes, so two people editing the same job no longer erase each other.
Deleting a customer's data as a feature (risk F)
What not to do now: split into services, or move away from PostgreSQL. Neither solves a risk above, and both would take the team's next six months.
5. Decision log
Keep one codebase; strengthen the modules inside it.
Why: the modules are already clear, and the team is six people.
Alternatives: separate services for planning and billing.
Revisit when: a module needs to scale or release on its own, or the team passes about 15 engineers.
A job queue in PostgreSQL, not a message broker.
Why: one database to run, back up and reason about.
Alternatives: Kafka or a cloud queue.
Revisit when: the queue carries more than integrations, or volume outgrows one database.
Sync by recorded changes.
Why: it is the only option that stops lost work for people offline.
Alternatives: lock a job while one person edits it, which fails exactly when there is no signal.
Revisit when: the new sync has run for three months with a few customers.
6. Walkthrough
One hour with the founders and the engineers: the findings, questions, and the order of work agreed. The team then planned items 1 to 4 for the next six weeks.