Faktorial.AI Faktorial.AI Asynkron autonomous engineering
Run a Pilot
Reference case

BokaBra shows what Faktorial can carry.

A real booking system, not a demo: public booking, admin, calendar, payments, CRM, CMS, integrations, auth, tenant scoping, migrations, and tests.

See estimate See system
System overview

Three product layers that have to work together.

BokaBra consists of a public customer experience, a broad admin/backoffice, and a backend platform that ties together tenancy, the data model, integrations, and payments.

Customer surface
Public websiteTenant profile, content, news, images, and booking entry points.
Booking flowServices, time slots, group sessions, customer details, and rules.
Customer sessionMagic-link and cookie session separate from admin auth.
PaymentCheckout, deadlines, and online payment status.
Admin
OperationsBookings, calendar, queue, reports, unavailable times, and schedule deviations.
ConfigurationServices, resources, schedules, articles, prices, and planning blocks.
RelationshipsCustomers, reviews, tags, custom fields, newsletter, and history.
FinanceGift cards, campaigns, batch invoicing, reports, and accounting articles.
Platform
React/ViteFrontend with feature modules, admin routes, and public routes.
Express APIBackend route handlers, tenant filtering, jobs, webhooks, and integration logic.
PostgresSupabase Cloud, migrations, tables, down files, and backend-only DB access.
ClerkAdmin identity through organization and tenant scope in the backend.
Inventoried volume

This is the size of the system.

The numbers come from the repository, specs, routes, backend modules, migrations, and measured LOC across frontend, backend, and tests.

Feature specs66
Frontend routes57
Admin nav entries41
Frontend modules41
Backend modules46
Backend route files54
DB migrations74 + 74
Spec/docs LOC2,959
Modules

The product's main parts.

Each module is its own work surface, but they share the data model, tenant scope, auth, component patterns, API contracts, and verification.

01

Public web and customer flow

Website, booking, customer sessions, group sessions, and payment flow.

02

Booking operations

Admin creation, lists, calendar, queue, availability, reports, and changes.

03

Services and schedules

Service catalog, articles, resources, schedule editor, rules, and planning blocks.

04

Customers and CRM

Customer registry, history, comments, GDPR flows, tags, custom fields, and reviews.

05

Communication

Templates, logs, channel settings, message jobs, newsletter, and audit trail.

06

Payments and finance

Stripe, Qvickly, payment events, gift cards, campaigns, batch invoicing, and Spiris.

07

Website/CMS

Settings, home page, menu, news, image archive, and public website routes.

08

Access control

Vendor surfaces, credentials, access grants, and booking-linked time margins.

09

Integrations

Google Calendar, iCal, webhooks, Mailchimp, metrics, AI assistant, and audit logs.

10

Auth and operations

Clerk, tenant scope, customer magic link, local bypass, migrations, and admin shell.

Build anatomy

How BokaBra is built.

The architecture is conventional enough to understand, but broad enough to test whether an AI-driven delivery model can handle real dependencies.

Frontend

  • React/Vite application with admin and public routes.
  • Feature modules for bookings, customers, schedules, payments, CMS, access control, and integrations.
  • Admin shell with dashboard, sidebar, settings areas, and support view.
  • The frontend goes through the Express API, never directly to Supabase.

Backend

  • Express API with 241 inventoried route handlers.
  • The backend is the only DB client and owns tenant filtering.
  • Feature modules for bookings, payments, CRM, messages, webhooks, and calendar.
  • Jobs, webhooks, metrics, audit logs, rate limiting, and CSRF.

Data and identity

  • Postgres on Supabase Cloud with migrations and down files.
  • Clerk admin auth where the organization is the tenant source.
  • Tenant scoping from Clerk orgId to x-booking-tenant-id to tenant_id.
  • The customer's magic-link session is separate from admin identity.
Time estimate

Reasonable build volume per area.

The estimate assumes a sharp, highly driven senior web developer building the functionality that actually exists in BokaBra. The relevant comparison is cost basis: senior developer salary cost versus Faktorial's agent-assisted model.

Area Man-hours Comment
Public website and customer flow270-510Public routes, booking flow, group sessions, customer session, and payment surface.
Booking operations750-1,350The heaviest operational surface: calendar, queue, availability, reports, and lifecycle.
Services, resources, and schedules430-760The core configuration that determines what can be booked, when, and by whom.
Customers and CRM500-900Customer registry, history, GDPR, tags, custom fields, reviews, and newsletter.
Messages and communication300-560Templates, logs, channel settings, jobs, and delivery trail.
Payments and finance700-1,250Stripe, Qvickly, gift cards, campaigns, batch invoicing, reporting, and Spiris.
Website/CMS300-520The tenant's public content, menu, news, images, and website settings.
Access control160-320Settings, grants, and vendor surfaces. Several vendors are mainly config/spec surfaces.
Integrations and automation470-850Calendar, iCal, webhooks, Mailchimp, metrics, AI assistant, audit, and protection.
Auth, tenancy, and operations260-515Clerk, tenant scope, customer auth, Supabase architecture, migrations, and admin shell.
Total build volume4,140-7,535Cost basis: 3,726,000-6,781,500 SEK at 900 SEK/hour.

Faktorial source cost: 12 days x 4 hours/day x 1,500 SEK/hour = 72,000 SEK, plus 3,000 SEK in OpenAI + Claude subscription fees, for a total of 75,000 SEK. The agent/source window was 96 hours, but the priced senior developer input is 48 hours.

LOC in the detail tables is traced from files that clearly belong to each item across frontend, backend, and tests. A value of 0 means no separate implementation was found in the current codebase, or that the item only exists as configuration/spec.

Public website and customer flow
ItemMan-hoursLOC
Public company page with company profile, content, reviews, and booking entry points60-1104,526
Website home page, menu/pages, news articles, and image archive0-00
Public APIs for services, availability, customer creation, and booking creation60-1151,173
Public booking configuration: color/theme, flow variant, list layout, time display, and allowed booking methods45-851,732
Customer payment page for bookings that require online payment45-902,159
Customer sessions via magic link/cookie, separate from admin auth25-50326
Public group sessions with booking flow for sessions/classes35-602,766
Booking operations
ItemMan-hoursLOC
Booking creation in admin50-901,884
Booking list with filtering, detail view/editor, and lifecycle actions90-1609,274
Booking report and payment report40-751,852
Staff calendar and staff calendar editor100-1802,166
Group sessions with list, editor, publishing, cancellation, and participant booking95-1603,709
Queue/waitlist for fully booked slots, including queue settings and queue operations65-1205,312
Availability calculation across schedules, resources, services, and bookings145-2602,479
Unavailable times and planning blocks70-1304,196
Schedule exceptions and report of schedule deviations30-60769
Moving/changing/cancelling bookings and related backend side effects65-115826
Services, resources, and schedules
ItemMan-hoursLOC
Service catalog with list, editor, prices, status, and relationships90-1604,663
Articles/products that can be used in finance and pricing flows35-651,925
Resource list and resource editor for bookable resources55-953,002
Schedule list and schedule editor100-1804,382
Schedule tabs for settings, linked resources, linked services, advanced rules, and exceptions55-110456
Booking intervals, validity periods, booking horizon, cutoffs, and timezone in the data model10-25105
Planning blocks for more advanced operational planning85-1252,307
Customers and CRM
ItemMan-hoursLOC
Customer list and customer editor70-1255,267
Customer comments, customer history, and links to bookings, payments, messages, and reviews80-1451,994
Customer import/export, GDPR export, and anonymization/deletion via the customer ownership surface95-1701,526
Tags for customers and bookings35-601,787
Custom fields for bookings, customers, and services80-1452,241
Reviews with status/moderation45-801,992
Newsletter: logs, templates, and segment/send surface65-1202,106
Mailchimp settings as integration surface30-551,570
Messages and communication
ItemMan-hoursLOC
Message templates with channel and language variants60-1102,069
Message log for SMS, email, and push35-701,216
Settings for booking-related messages35-701,799
Backend message jobs for tick/run and delivery work80-1502,873
Newsletter log and newsletter templates45-901,947
Delivery and audit trail for communication45-701,633
Payments and finance
ItemMan-hoursLOC
Payment settings with provider selection and tenant configuration50-902,405
Stripe configuration and Stripe checkout flows120-2154,491
Qvickly configuration and Qvickly checkout flows90-1602,223
Payment events linked to bookings and reporting75-1401,160
Payment deadline, paid/unpaid/pending/refunded status in the data model25-50466
Gift cards and campaign codes with transaction history95-1704,861
Batch invoicing with log of invoice runs90-1603,140
Spiris standard articles and integration status50-901,369
Price-article mappings between services and accounting articles40-70986
Printable booking copies/templates65-105891
Website/CMS
ItemMan-hoursLOC
Website home settings40-702,059
Website booking settings35-651,606
Website menu settings30-501,125
Website news list and news editor50-851,661
Website image archive with upload, metadata, usage, and delete/update75-1402,772
Public website routes that render the tenant's website content70-110993
Access control
ItemMan-hoursLOC
Access control settings with global enable/disable, selected vendor, and time margins around bookings55-1105,158
Access grants linked to bookings35-801,526
Vendor surfaces/specs for RCO, Aptus, Axema, Parakey, Amido, Telkey, Accessy, and Zesec45-954,037
API credentials and vendor-specific config fields25-351,262
Rules for deleting old bookings and notifying via email/SMS0-00
Integrations and automation
ItemMan-hoursLOC
Google Calendar OAuth25-50220
Calendar sync tokens and iCal flows75-1354,293
Webhook settings, URL list, event catalog, logs, retry/test/delivery jobs110-2004,462
Mailchimp settings45-802,557
Spiris accounting settings35-651,369
OpenTelemetry/metrics surface and /metrics35-651,228
Health endpoint1-24
AI chat/admin assistant surface85-1505,488
Audit logs25-45718
Rate limiting and CSRF34-58544
Auth, tenancy, and operations
ItemMan-hoursLOC
Clerk admin auth with organization as tenant source50-100687
Tenant scope via x-booking-tenant-id and backend filtering50-110724
Customer magic-link auth separate from admin auth25-50326
Local admin bypass for agent/manual testing5-1046
Supabase/Postgres as database, while the frontend only talks to the Express backend10-2573
Migrations with down files and backend-first data model25-55498
Admin shell with dashboard, sidebar/navigation, settings areas, and support view95-1655,841
Why the case works

BokaBra is usefully uncomfortable.

It has enough dependencies to be an honest reference case: UI, API, auth, data, integrations, payments, migrations, tests, and product logic all have to fit together.

What Faktorial demonstrates here

  • The backlog can be split into clear feature surfaces without losing system context.
  • Agent work can connect to specs, existing patterns, migrations, and tests.
  • Delivery can be judged by real artifacts: routes, handlers, views, data model, and test code.
  • Large product areas can be built iteratively without becoming a one-off demo.
01

The specification is broken into narrow deliverable surfaces, such as booking list, webhook log, payment settings, or schedule editor.

02

Faktorial uses the codebase's own patterns, data contracts, and components instead of inventing parallel solutions.

03

Frontend, backend, migrations, and tests are connected within the same scope, making the result verifiable.

04

Knowledge from each delivery becomes new system material: specs, ADRs, test cases, and reusable implementations.

Important: external agreements, vendor certifications, brand identity work, and larger product-strategy rework are not included in the estimate. Access control includes several vendor surfaces where not everything is a full external integration in the current code.