Virksom

Overview

An operations system built around the everyday needs of a business.

Details

Project type: Operations platform, web and mobile
My role: Defined, designed and implemented the platform, and ran the rollout to daily use.
Category: Systems
Status: Live2026
AI in the product: No runtime AIVirksom contains no runtime AI. Every engine in the product, from HSE suggestions and register status to offer and invoice calculations, is deterministic and unit-tested.

What I did

Defined the scope and the data model together with the business owner
Designed the workflows and interface for office use and active field work
Implemented the web application, database, permissions and native mobile wrappers
Tested the important flows, verified access rules and ran the production rollout

AI in the process

Planned, designed and implemented with AI-assisted development. AI tools helped me explore approaches, draft implementation and tests, and review code. I decided the scope, the structure, what was tested and what shipped.

Built with

TypeScript: Application code across the stack
Next.js: Application framework and server rendering
Tailwind CSS: Interface styling
Supabase (PostgreSQL): Database, authentication and row-level security
Capacitor: iOS and Android wrappers with camera and biometric sign-in
Vercel: Hosting with pull-request based deployment
Git and GitHub: Branch and pull-request workflow

Open Virksom login(opens in a new tab)Discuss a project like this

Next project

Commissioning Bench

The Virksom sign-in screen: the product name above an operations-dashboard subtitle, with an email and password form on a deep blue ground

The need

A small trade business runs projects, customers, bookings, deviations, HSE documentation, employees, offers and invoicing across many disconnected tools. The administrative load lands on the owner, and the people in the field cannot see or update what they need while they are on site.

The business needed one internal system that follows its actual workflow, is usable on a phone in active field work, and protects company and customer data.

My contribution

I worked with the owner from the first conversation: mapping how work moves from a customer enquiry to an invoice, deciding what the system must own and what it can leave alone, and translating that into a data model and a set of screens.

I then designed and implemented the application end to end: the web interface, the database and permissions, the native wrappers for iOS and Android, and the tests around the flows the business depends on.

The experience

The product is organised around the units the business already thinks in: projects, customers, bookings, milestones, teams, HSE registers, deviations and change orders, offers and invoicing. Each area is a plain, scannable screen with the same layout rules, so a new employee recognises the pattern after one module.

The mobile wrappers add what field work needs: the camera for documentation, biometric sign-in, and a layout that works with one thumb. Customers receive tokenised confirmation links, so a change order can be approved without an account.

The Virksom dashboard for a plumbing business: a good-morning greeting, a row of figures for active projects, booked teams, revenue and invoices, a high-risk count, and the week's team plan as a timeline

The Virksom project list: a table of jobs with the customer, the trade, the status, a risk level, the assigned team and the value of each

The Virksom team screen: an access-and-roles panel with an invitation form, above two teams showing their capacity for the week, the job each is on now and the one after it

How it works

One PostgreSQL model in Supabase with row-level security. Each role only reads and writes the rows it is allowed to see; anonymous access was verified to return zero rows.
Role-based access for owner, office and field roles, enforced in the database rather than only in the interface.
Customer confirmation links are single-purpose tokens with idempotent confirmation, so a link can be opened twice without creating two approvals.
Web and native mobile share one codebase; Capacitor provides camera, biometric authentication and haptics on iOS and Android.
Files are stored in object storage behind presigned URLs, and invoices are prepared for mirroring to the accounting system.

Decision

Rules, not models, for the logic the business is accountable for

Context: HSE status, competence warnings and price calculations must be explainable to an inspector and correct every time.
What I decided: Every engine is a pure, unit-tested rule matcher. AI was used to build the product, not placed inside it.
Trade-off: The system cannot answer open questions; it can only apply the rules it was given. That is the right limit for a compliance and invoicing tool.

Validation and delivery

The important flows are covered by automated tests, and the access rules were checked directly against the database before real data went in. The owner walked through the product with real jobs before rollout, and example data was removed at go-live.

Virksom went live at virksom.no with the owner and two employees as the first users, and it is used in day-to-day operations.

Outcome and reflection

Delivered for day-to-day operations, with real users and real data. The strongest lesson was the value of building the deterministic system first: understanding the work in practice made every later product decision easier, and it gave a clear boundary for where AI belongs.