Report · excerpt
1. Management summary
For its current “prototype” status, the app is cleanly and thoughtfully built – data model, backup concept and baseline security are good. A handful of pilot customers is within reach. For hundreds of business customers, however, what is missing is not server power but a foundation that is ready for further development, scaling and monitoring.
| Area | Status | Assessment |
|---|---|---|
| Security (login/session) | urgent | Solid groundwork, some gaps for multi-user operation |
| Architecture / scalability | urgent | Monolith (one process, one server); target architecture recommended |
| Code quality | important | Well commented, but highly concentrated and without tests |
| Operations / deployment | OK | Above average for this level of maturity |
| Commercialisation | important | No company-account or billing model |
| Data protection (FADP/GDPR) | important | No documented processes found |
2. Findings (security excerpt)
Positive
- Passwords hashed with a modern, slow algorithm; old hashes migrate automatically on next login.
- Session cookies set correctly (HttpOnly, SameSite, Secure).
- Brute-force protection: lockout after repeated failed attempts.
- Security headers (HSTS, CSP etc.) configured cleanly – above what you usually see in solo projects.
- Consistently parameterised database queries; no SQL injection found.
Findings
- Medium
Sessions and rate limits only in memory
Every restart logs out all users, the structures grow without limit under attack, and a second server process would have its own inconsistent sessions.
- Medium
No CSRF token
State-changing actions rely on SameSite cookies alone. For admin actions an explicit token is more robust.
- Low
Default credentials in code
A fallback user with password sits in the source code. Overridden in production, but avoidable.
- Low
No self-service password reset
Access only via admin invitations – with more customers this becomes a support burden.
3. Scalability: not more servers, but the right model
Technically, today’s architecture is enough for the first few dozen customers. SQLite is not the bottleneck in the short term – for a mostly read-heavy app it is pragmatic. The real limit should be measured with load tests, not derived from the number of accounts.
The actual blocker is the data model: the system knows individual logins but no company that owns several users, roles, licences and a subscription status. The next stage first needs a robust B2B account model – not more servers.
4. Target architecture: modularise in a controlled way instead of rebuilding
| Component | Today | Target |
|---|---|---|
| Backend | One process without a framework; routing, login, business logic and data access in one file | Modular API backend (e.g. FastAPI) with separate, testable modules |
| Database | SQLite file on the server; schema changes made directly from code | PostgreSQL with versioned migrations |
| Frontend | One very large HTML file with embedded JavaScript | Component-based frontend that gets data only via the API |
| Operations | One server, backup on the same machine, no monitoring | Off-site backup, tested restore, monitoring and alerting |
The valuable business logic is first protected with tests and then moved over step by step – a refactoring of structure, not a rewrite of the logic.
5. Prioritised roadmap
Before the first paying business customer (must)
- Clarify rights to third-party data and licences for commercial use
- Introduce a simple company-account model (organisation with several users)
- Basic monitoring and alerting for uptime, imports, backups and errors
- Backup outside the production server and a tested restore
- Document data protection and data lifecycle (incl. data sent to external AI services)
- Protect critical business logic with regression tests
Before scaling (should)
- Complete the account and subscription model (roles, seats, cancellation, suspension)
- Automate payment and billing
- Modularise the backend and establish an API
- Move sessions and rate limits to the database or a central store
- Migrate to PostgreSQL, modularise the frontend step by step, add CI and load tests
6. Verdict
A good technical starting point for the next product phase, but not yet a fully scalable B2B platform. Getting there takes several targeted extensions – not a restart.