Skip to content
Based in Kyiv, Ukraine (UTC+2/+3). Live overlap 9 AM – 1 PM ET every working day, plus the full UK and EU working day.
Reference build · Based on patterns from prior work Field Services · Logistics · Manufacturing PostgreSQL · Clean Data Model

Three architectures: dispatch, document intake and material ledger

Most operational problems don't need fancy code — they need the database to refuse bad data before it gets saved. Below are reference PostgreSQL schemas, shown in full, and data flows for three common problems: scheduling field crews without double bookings, extracting incoming documents without duplicate entry, and tracking materials through an append-only ledger.

Status
Reference build · Based on patterns from prior work. Reference schemas, shown in full.
Database
PostgreSQL (constraints, triggers, views, btree_gist)
Built-in checks
Built-in checks: no double booking, no duplicate entry, no overwritten balances
Ownership
Deployed to your repository and cloud account
Reference build Field Services · Construction & Installation

01 · Field dispatch board

The problem it solves

Jobs come in by phone, email and web form. A dispatcher keeps the schedule in a spreadsheet or whiteboard, checks who's certified for what from memory, and finds out about a double booking when two technicians call from the same site — or none show up.

Data model (simplified)

TableHolds
techniciansName, home base, active status
skillsTrade or certification: refrigerant handling, roofing, glazing, welding
technician_skillsWho holds which skill, and until when it's valid
sitesCustomer, address, access notes
jobsSite, required skill, time window, priority, status
assignmentsWhich technician does which job, from when to when
job_eventsEvery status change: who, when, from the office or the field

The constraint that does the dispatcher's double-checking

A technician can't be booked for two overlapping jobs. The database rejects it via exclusion constraints, whatever the web interface or an import script attempts to write.

-- PostgreSQL Exclusion Constraint stopping double-booking
create extension if not exists btree_gist;

create table assignments (
  id            bigint generated always as identity primary key,
  job_id        bigint not null references jobs(id),
  technician_id bigint not null references technicians(id),
  starts_at     timestamptz not null,
  ends_at       timestamptz not null,
  cancelled     boolean not null default false,
  check (ends_at > starts_at),
  exclude using gist (
    technician_id with =,
    tstzrange(starts_at, ends_at) with &&
  ) where (not cancelled)
);

*Skill and certification checks execute in the same transaction: an assignment is refused if the technician does not hold the job's required trade skill, or if it expires before the job date.

How a job moves

1 · Intake

Calls, emails and forms become one job record with site, required skill, and time window. Duplicate requests for the same site and day are flagged.

2 · Scheduling board

The dispatcher drags jobs onto technician timelines. Overlaps and missing certifications are refused with the reason shown on screen.

3 · Field updates

Technicians change status from their phone — en route, on site, completed — and attach job photos and customer notes directly.

4 · Close-out

A finished job records actual materials used (feeding the material ledger) and generates an invoice draft for office approval.

What fails safely
  • Technician unavailable: reassigning a job keeps the complete assignment history; nothing is overwritten.
  • Conflicting edits: two dispatchers moving the same job — the second save is refused with optimistic locking and the current state is refreshed.
  • Spreadsheet imports: rows breaking validation rules land in an actionable review queue instead of corrupting the schedule.
Not built in: custom route optimization algorithms. Where drive-time optimization matters, we connect dedicated routing APIs rather than reinventing GIS solvers.
Comparable build: Dispatch board on its own: Focused Micro-System ($5,000–$8,000). With mobile web app, materials and invoicing: Custom Operational CRM ($15,000–$35,000).
Reference build Logistics & Distribution · B2B Manufacturing

02 · Document intake pipeline

The problem it solves

Supplier invoices, customer POs, bills of lading and delivery receipts arrive as PDFs, scans and email attachments. Someone re-types them into the system, matches them to orders by eye, and occasionally enters the same invoice twice.

Data model (simplified)

TableHolds
documentsSource, file fingerprint (SHA-256), document type, status
extracted_fieldsField, value, page it came from, model and prompt version
validation_resultsEach rule checked, passed or failed, and why
review_tasksWhat a person needs to look at, who took it, the decision
posted_recordsThe invoice, order or receipt written to your system, linked to source file

The constraints that stop duplicate entry

The same file is never processed twice, and the same supplier invoice number can't be posted twice. Likely duplicates go to review.

-- Deduplication by cryptographic file hash and supplier invoice number
create table documents (
  id          bigint generated always as identity primary key,
  source      text not null check (source in ('email', 'upload', 'api')),
  file_sha256 text not null unique,     -- the exact file cannot be processed twice
  doc_type    text,
  status      text not null default 'received'
              check (status in ('received', 'extracted', 'validated',
                                'needs_review', 'posted', 'rejected')),
  received_at timestamptz not null default now()
);

-- the same supplier invoice number can't be posted twice, even under a different file
create unique index one_invoice_per_supplier
  on supplier_invoices (supplier_id, invoice_number);

How a document moves

1 · Intake

A shared inbox, upload folder or webhook receives the file. SHA-256 fingerprint checked first; duplicate stops here.

2 · Extraction

AI / OCR reads the document and returns typed fields — supplier, line items, totals. No production tables written yet.

3 · Validation

Code validates arithmetic: line items match total, supplier exists, quantities and prices match PO within ±2% tolerance.

4 · Review queue

Discrepancies go to an operator with side-by-side original PDF preview. Operator corrections tune future extraction rules.

5 · Posting

Validated records commit in one database transaction, permanently linked to the original file for instant audit drill-down.

What fails safely
  • Unreadable scan: diverts to manual review with the extraction failure reason; no numbers are ever guessed.
  • AI provider temporary outage: incoming files wait in a background queue with automatic retries until the provider responds.
  • Model updates: regression benchmark of past verified documents runs before any new model or prompt version deploys.
Comparable build: One document type ingestion workflow into your existing system: AI Workflow build, from $3,500.
Reference build · Based on patterns from prior work B2B Manufacturing · Distribution · Construction

03 · Material movement ledger

The problem it solves

Stock levels live in a spreadsheet that someone edits by hand. Material goes to a job and isn't written off; a correction overwrites the old number; at month-end nobody can say where 40 sheets of steel or 15 rolls of TPO membrane went.

The fundamental rule: Stock on hand is never typed in. It is always the sum of every movement — receipts, issues to jobs, transfers, returns, and adjustments. A mistake is fixed with a reversing entry, not by editing historical rows. Every number traces back to the document and operator behind it.

Data model (simplified)

TableHolds
itemsMaterial, unit, unit conversions (sheet → m², roll → linear ft)
locationsWarehouse, shop floor, truck, job site
stock_movementsEvery movement: item, location, quantity, reason, document, who, when
jobsWhere material was issued to, linking actual cost to bid
stock_countsPhysical counts, used to reconcile against the ledger

The schema that keeps history honest

Append-only security: application roles have rights to insert movements, but update and delete permissions are revoked at the database level.

-- Append-only inventory ledger: changes are logged, never overwritten
create table stock_movements (
  id           bigint generated always as identity primary key,
  item_id      bigint not null references items(id),
  location_id  bigint not null references locations(id),
  qty          numeric(14,3) not null check (qty <> 0),   -- positive: in, negative: out
  reason       text not null check (reason in
               ('receipt', 'issue_to_job', 'transfer', 'return', 'adjustment')),
  job_id       bigint references jobs(id),
  document_ref text,
  created_by   bigint not null references users(id),
  created_at   timestamptz not null default now()
);

-- the application can only append records, never alter past events
revoke update, delete on stock_movements from app_role;

-- live stock on hand is computed dynamically
create view stock_on_hand as
  select item_id, location_id, sum(qty) as on_hand
  from stock_movements
  group by item_id, location_id;

*A transfer is recorded as two movements in a single transaction (negative at source, positive at destination). Material cannot disappear between locations.

How material moves

1 · Receipt

Delivery verified against the vendor purchase order. Short or over deliveries are immediately flagged.

2 · Issue to job

Material written off to a specific job ID, so job cost includes actual materials pulled, not just theoretical takeoffs.

3 · Transfer

Warehouse truck site, each transit step timestamped with the driver or technician accountable.

4 · Reconciliation

Physical cycle counts compare to the ledger. Discrepancies generate adjustment entries requiring supervisor sign-off.

How balance drift is caught
  • Scheduled reconciliation check: item and location totals are recomputed from the full movement journal and checked against expected stock balances; alerts fire on any mismatch.
  • Mandatory adjustment approvals: inventory write-offs require an explicit reason code and manager authorization; no quiet quantity changes.
  • Estimate vs actual tracking: material consumed on a job compares against the estimated budget, exposing job site overruns before invoice closeout.
Comparable build: Material ledger standalone: Focused Micro-System ($5,000–$8,000). Integrated into operations with jobs, dispatch and estimating: Custom Operational CRM ($15,000–$35,000).
Shared principles

Five rules we apply to every system

The architectural foundation across every database, API gateway, and internal tool engineered by SolviLab.

01

The database enforces the rules, not just the screen.

Overlaps, duplicates and impossible values are refused by constraints, so an import, an integration or a bug in the interface can't get around them.

02

History is added to, never overwritten.

Anything involving money, stock or status keeps a full trail of who changed what and when. A mistake is fixed with a reversing entry.

03

Outside inputs are validated before they're saved.

Emails, files, AI output and third-party APIs land in a staging step first. Only checked data reaches your production records.

04

Every failure has a place to go.

Retries for temporary network errors, a review queue for anomalies. Nothing is silently dropped or lost in unmonitored logs.

05

Boring technology, sized to your load.

PostgreSQL does most of the heavy lifting. We add a queue, cache or extra microservice only when your actual volume requires it.

Ownership

Built in your accounts. Yours to keep.

We build internal software on standard open-source foundations that live entirely on your infrastructure.

You own the code and the data

Repositories, database schemas, migrations and Docker setups live in your GitHub or GitLab and run on your servers or cloud account — Hetzner, DigitalOcean, AWS or your own VPS. Storage encryption and backups are configured on your infrastructure from day one.

No vendor lock-in

Open, widely supported technologies — Vue / Nuxt, Laravel, PostgreSQL, Docker — and documented REST APIs. Any competent in-house or outside team can maintain and extend the code without paying us monthly licensing fees.

NDA before your data

We sign a mutual NDA before you share internal documents, workflows or database access. Your proprietary business rules and customer records are never reused for another client or shown on this site.

Next step

Your blueprint comes out of the audit

In 5–7 working days we map how jobs, documents or materials move through your business today, and deliver four tangible assets:

1 · Bottleneck MappingWorkflow bottleneck analysis and operational constraints
2 · Clickable PrototypeClickable core-flow prototype (5–6 screens)
3 · Written Build ScopeDetailed screen logic, user roles, and integration requirements
4 · Fixed-Price QuoteLocked build price and milestone schedule. Yours to keep, whoever builds it.
Book an Operations Audit (From $1,000) Fee credited 100% toward a Custom CRM build if signed within 60 days

Questions technical teams ask

Direct, verifiable answers about database schemas, migration code, load sizing, and team handovers.

No client data is shown. The material ledger follows a pattern from systems our team designed before SolviLab; the schemas themselves are our reference builds, so we can show them in full without exposing anyone's proprietary business operations.
Yes. On a call we can walk through the complete schema and database migrations for any of the three blueprints, and answer questions about any table, index or constraint.
That depends on your volume, so we size it during the audit. For most operations teams of 10–200 people, a single well-indexed PostgreSQL database handles tens of thousands of daily records with ease without distributed complexity.
Yes, through their APIs or automated file exports — QuickBooks, Procore, HubSpot, ERPs, or Google Sheets. The audit lists which connections are needed and what each integration requires.
Yes. The output of the Operations Audit is an independent technical specification and prototype that belongs to you. You can build it with your in-house team, with another contractor, or with us.

Related systems & analysis

Next step

Want to see what your data model would look like?

Book a 30-minute call. Tell us how jobs, documents or materials move today — we'll sketch the core tables and tell you honestly whether you need a custom system or a few fixes to what you have.

Prefer email? Reach us at info@solvilab.com

Fixed price agreed before build
100% code ownership
Live overlap 9 AM – 1 PM ET