Stapilo: full technical reference

A detailed description of how Stapilo is built: the applications, how they connect, the data model, the AI agent, integrations, quality controls, security and the measured effort. All figures were measured from the codebase and the live system on 25–26 October 2026. Security-sensitive details (server addresses, keys, internal network layout) are deliberately left out.

1. At a glance

2. Applications

3. Backend architecture

• One backend codebase, five processes: a fast API; the agent process (paying businesses' AI); the sales door (anonymous visitors' AI, the same program started separately so a visitor-side problem can't take down a paying business's AI; enforced by a guard); a worker for background jobs; and a real-time service.
• Four servers on a private network (application, database, worker, real-time). Each production process runs in two copies so deployments swap without downtime.
• Data: one PostgreSQL database accessed through Prisma; Redis for caching, rate limits and real-time; a PostgreSQL-backed job queue (175 queues) with a single entry point for sending jobs and a single way to define workers.
• Media: object storage for files and a streaming video service with a built-in player; a media file is only ever deleted after a check confirms nothing references it.
• Monitoring: error tracking for backend and web apps with source maps; an hourly health snapshot checks every production process.

4. Data model and multi-tenancy

• One person record per customer (the contact) and one access table for every kind of entitlement (course, event, community, product). New features add a resource type, never a new membership table.
• One form model covers quizzes, polls, surveys, tests and registrations, through field types and behaviour flags.
• One history per customer: every action (purchase, visit, answer, message, webinar attendance) is written through a single function to the customer's timeline, attached to the exact item it concerns (1.69 million events recorded so far).
• Tenant isolation: 283 of the 336 tables are automatically scoped to one business: a scoped database client adds the business filter to every read and write, and callers can't override it. Hand-written SQL must include the business condition or the build fails; a security audit walked all 338 raw-SQL sites and found no leak between businesses.
• Deletes that matter: deleting anything people depend on first reports what would be affected (registrations, answers, posts); soft deletion with restore for key records.

5. The AI agent

• One engine for every agent, so timeouts, error reporting, cost tracking and prompt caching are shared rather than duplicated.
• The agent's map is the app's map: a "building" of rooms, tabs and sub-tabs that mirrors exactly what a person clicks through; two automated checks keep the agent's map and the app's screens identical. On every turn the agent knows which room, tab and record the person is looking at.
• Tools: 163 tools in 27 families (pages, courses, webinars, campaigns, inbox, ads, shop, bookings, settings and more). Each turn holds a small everyday kit plus a menu from which a family of tools is loaded when needed, keeping prompts small.
• One conversation per business, shared by the whole team across rooms; each line is stamped with who wrote it and where. The agent reads a moving window of recent conversation by size, never summaries.
• Safety: risky actions (publishing, sending to many people, deleting, refunding) wait for the owner's approval.
• Cost control: the fixed start of every prompt is kept byte-identical between messages (enforced by a guard) so the provider's cache applies; every turn's cost is recorded per business. Measured AI cost: about $10–30 per business per month.
• Outside AI: an owner's own AI assistant can operate Stapilo through a secure connection, with exactly the owner's permissions.

6. Integrations

7. Quality controls

• "One front door" rule: each domain has exactly one official entry point (granting access, checking access, recording an event, sending a job, submitting a form, deleting media). A guard fails the build if any code goes around it.
• Ten representative guards: business-scoped raw SQL; visitor AI and business AI in separate processes; secrets stay encrypted; one function checks access; one function grants access; granting access after a payment must be checked, never ignored; one function writes customer history; deletes report their impact; one way to enqueue jobs; the cached prompt prefix stays stable. A further check verifies that guards actually scan files, so a blind guard can't pass.
• Continuous integration on every pull request: unit, integration (real PostgreSQL, all migrations applied, schema drift check), route and front-end tests, translation parity, dependency security audit, linting, type-checking of every package, a full build, and end-to-end browser tests as a second required check. Changes merge only when all pass.
• Scheduled checks: nightly coverage, weekly mutation testing (the code is deliberately broken to prove tests catch it, with a ratchet that may only improve), a weekly scan for tests that would break on a future date, dependency reports.
• AI-assisted development: 94% of changes were written together with an AI coding assistant; all of them pass the same tests and guards as any other change.

8. Security

• Authentication: customers sign in with a one-time code (and Google sign-in); sessions are HttpOnly, Secure cookies scoped to one business; the customer identity always comes from the session, never from the request.
• Secrets: every production key is stored encrypted, each server able to decrypt only what it needs; third-party credentials in the database are encrypted with AES-256-GCM, and production refuses to start without the key.
• Isolation of user-made content: AI- and business-made pages and apps run on separate origins with no access to sessions.
• Abuse protection: 399 route-level rate limits, flood limits at the web server, bounded rate-limit keys, payment webhook limits, input validation on write endpoints, security headers enforced by a guard.
• Audits: four whole-platform security audits in October 2026 found 143 issues (3 critical, 17 high); 133 are fixed, the rest are owner actions or deliberate decisions. The first audit concluded that the wall between businesses held everywhere it was traced and that no secrets were committed.
• Backups: the database is copied every 6 hours to three separate providers, one with a compliance lock that prevents deletion for 7 days; weekly and monthly long-term copies; every off-site copy is encrypted; media and original videos are copied nightly; failed copies raise an alert. Not yet done: a recorded full restore drill from the off-site copies.

9. Effort

Seven people contributed code in this period (the founder and six developers); 645 person-days of recorded work; the founder active on 194 of 250 days. Large removals in September and October are deliberate rewrites (the old dashboard and the old AI engine replaced). Development spans about 18 months in total: an earlier version (in a separate repository, not counted here), then the current codebase since 18 February 2026, which every figure on this page measures; at least 8 months with a team of five.

10. Code review on request

For serious investors, a technical reviewer they name can be given time-limited, read-only access to a clean copy of the codebase (without secrets or history that contains them), under a confidentiality agreement.