smallbox

← All articles

What you could build

What kinds of SaaS and product systems does Smallbox build — and why do they share one backend shape?

The types of SaaS and backend systems Smallbox Labs builds

Smallbox Labs builds backend systems. The products look different from the outside — a marketplace, a billing dashboard, a learning platform — but underneath they are close to the same machine, which is why one small studio can build across all of them with confidence instead of starting from zero each time.

This page is a plain list of the kinds of systems that fit. Two of them are real systems already running — CompanyGraph, a database of around 104,000 companies with screening, comparison and generated reports, and a gamified learning platform (see the cases) — and the rest share their shape closely enough to be familiar territory, not a stretch. The point isn't that Smallbox can build any software; it's that these particular systems share one backend shape it is built for.

What these systems have in common

Before the list, the thread that ties it together. Different on the surface, these systems share the same backend spine:

  • Many structured records, with roles and permissions deciding who can see and change what.
  • Search and filtering across those records, fast enough to stay useful as the numbers grow.
  • Workflows and state — records that move through steps, with rules about what each step allows.
  • Payments, subscriptions, quotas and credits — money and limits wired into the product, not bolted on.
  • Integrations with outside services, and the asynchronous background jobs that run them without blocking the person waiting.
  • Admin operations — a real place to run the system and answer "why did this fail" without opening the database.
  • A long tail of small business rules that has to stay understandable as the product grows, instead of scattering into four places nobody chose.
  • An operational half that fails visibly — the jobs, imports, emails, reports and external APIs surface a signal early enough to fix and move on, never silently. The test is whether the people running it can sleep at night.

Get that spine right once and each of the systems below is a variation on it, not a new beginning. The Foundation is that spine, built and running.

Marketplaces and multi-sided platforms

Service marketplaces, product marketplaces, rental and booking marketplaces, freelancer and gig platforms, B2B procurement, auction and bidding sites. The hard part is rarely the listings — it is the matching, the money moving between two sides, the trust and reputation records, and the operator's console for the disputes that arrive afterward.

Directories, listings and portals

Business directories, property and real-estate listings, job boards, classifieds, membership portals, partner and reseller portals, client and patient portals. Many records, structured search over them, and tight rules about who sees which slice — the permission model is as much the product as the content is.

Booking, scheduling and lead flow

Appointment and consultation booking, event ticketing, reservations, field-service scheduling and dispatch, lead capture and routing. The booking rules — availability, overlaps, time zones, the load moment when everyone arrives at once — are where the difficulty lives; the payment and the calendar invite are the easy glue. Worked examples: consultation booking, event ticketing, field-service scheduling.

Admin-heavy back offices and operations

Order management, inventory and warehouse systems, fulfillment, logistics and dispatch consoles, case management, internal operations tooling. These are systems whose whole value is the admin surface — the place a human runs the day. The database is never meant to be the interface.

Billing, payments and subscriptions

Subscription and SaaS billing, B2B invoicing, usage and metered billing, credit and quota systems, payment reconciliation, payroll bridges. Money records have to agree across the product, the payment provider and the customer's own books — and the discipline that keeps them agreeing is the real product. Worked example: a B2B billing dashboard.

Reporting, dashboards and data tools

Report generators, dashboards and BI views, screening and comparison tools, data-feed alerting, document and OCR pipelines, compliance and audit reporting. The reader trusts a number on the screen, so the work is in where that number comes from and how it is verified — not in drawing the chart. Worked examples: a templated report generator, data-feed alerting.

Workflow, intake and approval systems

Application and intake forms, approval routing, content-moderation queues, review and verification workflows, onboarding and KYC, helpdesk and ticketing. A record enters, moves through human and automated steps, and the system's job is to make the next decision visible to whoever owns it. Worked example: a content-moderation pipeline.

Content and communication systems

CMS-backed publishing, multichannel marketing across email and SMS, notification and reminder services, support chatbots grounded in your own content, surveys and forms. Sending is the easy part; owning consent, deliverability and the record of what was sent is the part that lasts. Worked examples: a CRM email campaigner, a multichannel suite.

Learning and gamified platforms

Course and LMS platforms, AI-tutor learning, gamified training and engagement, assessment and certification. The exciting feature — the tutor, the game layer — is rarely the company; the unglamorous spine of enrollment, progress and content is. This is a shape Smallbox has already built: a gamified learning platform whose activity is simulated through production code on every build. Worked example: a course platform with an AI tutor.

Integration and data-sync systems

Accounting sync, CRM sync, data import from spreadsheets and Airtable, API aggregators, ETL and pipeline orchestration, connector hubs. The danger is always at the seam — idempotency so you never double-post, schema-drift detection, validating data you did not design. Worked examples: syncing accounting records, importing semi-structured data.

AI-assisted product features

Support chatbots, document extraction, content moderation, code-review assistants, spreadsheet helpers, text and image generation wrapped as a real product. The model call is the easy twenty percent; the product is everything around it — accounts, storage, billing, the confidence gate, the human who corrects what the machine got wrong. Worked examples: a support chatbot, document extraction.

Monitoring, alerting and operational tooling

IoT device monitoring, market and data-feed alerting, health and status monitoring, scheduled batch and job systems. A false alert erodes trust and a missed one ends the contract, so the product is the judgment about when to speak — silence is a feature. Worked examples: IoT monitoring and alerts, market-data alerting.

One backend, many products

The reason these belong on one page is that they are one backend wearing different faces. That is also the honest boundary: Smallbox builds the backend and the structure — the records, the rules, the workflows, the integrations, and the operational half that has to fail visibly. It is strongest paired with whoever owns the product decisions and the design; it does not replace them. If your idea is somewhere in this list, the useful next step is not more code — it is the Foundation the whole list rides on, and one real workflow run through it end to end.

Articles describe the Foundation. The Foundation Map is the thing itself — accounts, admin, email, logging, and deployment, with one real workflow running through them.

← All articles