# Sample Architecture Review of a Java Startup | Alli Araghi

URL: https://araghi.eu/work/sample-review/

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.

1. **Five times the customers in 18 months,** and about ten times the jobs planned per day, mostly from Sweden.
2. **Swedish customers:** Swedish language and VAT, and customer data that stays in the EU.
3. **Accounting integrations:** jobs flow into the customers' accounting systems without anyone typing them twice.
4. **Work on site without a signal:** basements and new buildings often have none, and changes made offline must not be lost.
5. **Ship several times a week, without downtime.** Today releases happen on Friday evenings, with the app down for about 15 minutes.
6. **A technical due diligence** for the next funding round, in about a year.
7. **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.

1. **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. **Effort:** 2 to 3 days **Trade-off:** none worth naming; do this first.
2. **Indexes and per-company queries for the calendar** (risk C) **Effort:** 2 days **Trade-off:** a little more care with every new query; a query check in the test suite keeps it honest.
3. **Integrations through a job queue** (risk B) An outbox table in PostgreSQL and a worker that retries. **Effort:** 1 to 2 weeks **Trade-off:** updates reach the accounting system seconds later instead of at once, which nobody here needs to be instant.
4. **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. **Effort:** about 1 week **Trade-off:** database changes take two releases instead of one.
5. **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. **Effort:** 3 to 4 weeks **Trade-off:** the biggest change here, so it starts after 1 to 4 and is rolled out to a few customers first.
6. **Deleting a customer's data as a feature** (risk F) **Effort:** about 1 week

**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.

Want a review like this of your own system?

Book a 30-minute intro call

How the review works