Book a diagnostic

Custom software for growing companies, handed over to you

Verne builds web and mobile apps, internal tools, SaaS products and games around the way your business already works. Scope and price are agreed in writing before work starts. The source code, accounts and documentation are yours at handover, and your team or any developer you hire can run and extend it.

Scope your buildTry the example below

One spreadsheet row, rebuilt as a record

In the shared sheet, anyone can type “approved”. In the tool, each state has an owner and a rule. Step the request through and see who acts next.

Shared spreadsheet, as it is today.

RefItemAmountCost centreOwnerStatusNotes
PR-113Desk chairs ×4960OPS?ordered??
PR-114Laptop for new hire1,450SALESask financeapproved (I think)see email Tue
PR-115Printer toner120ADMINdonepaid by card

Purchase request

New
Ref
Item
Amount
Cost centre
  1. New
  2. In review
  3. Approved
  4. Done

Owner now

Requester

Fills in the request. The tool checks the cost centre before it can be sent.

  • 01 New, by requester

What we build

  • Web and mobile apps

    One product for the browser, iOS and Android, with sign-in, accounts and an admin view.

  • Internal tools and portals

    The spreadsheet, inbox and shared drive your team runs on, rebuilt as one tool with states and owners.

  • SaaS products

    Accounts, roles, plans and billing: the parts customers never praise but always notice.

  • Legacy modernisation

    Old systems replaced piece by piece, with old and new running side by side until the numbers match.

  • E-commerce platforms

    Stores, checkout and order flows connected to your stock and your couriers.

  • Games and 3D

    Mobile and web games, playable ads, and 3D product configurators with live prices.

For your engineers

Stack

TypeScript, React and Next.js on the web; React Native for iOS and Android; Node.js or Python services; PostgreSQL. Unity, Godot or Three.js for games and 3D.

Architecture

Records move through explicit states, and the server enforces who may move them. Role-based access, an append-only history per record, and feature flags for gradual rollout.

Delivery

Small pull requests, CI on every change, preview deployments for review, and automated tests on the flows customers use most.

Security

Dependency and secret scanning in CI, least-privilege roles, encryption in transit and at rest, and audit logs on admin actions.

How we cut scope

Every big product starts as a small one that works. We pick the one job the first version must do and write down what waits. You see the screens before we build them, then a working build every week.

We agree scope and price before work begins. If you want something outside that scope later, we say so, agree the change in writing, and only then build it.

Who owns the code

You do, once the work is delivered. We hand over the code repository, the documentation and the accounts at full delivery, so your team or another developer can run and extend it.

When your engineers build alongside ours, we set up tiered access to the repository for the length of the project. If you need the repository in your name from the first day, ask for it: we agree that clause in the contract, with matching safeguards for both sides.

Double-booked every Monday at nine

A Rotterdam haulage firm's dock-booking app had been rewritten twice by two agencies. Every Monday at 09:00, when carriers rushed to book the week, two trucks would turn up for the same door. Each rewrite moved the bug somewhere else.

The operations manager kept a whiteboard of the real bookings next to the screen.

  1. Reproduce the Monday rushEngineers replayed a Monday's booking traffic against a copy of the system, 400 requests in ninety seconds, until the double booking appeared on demand.
  2. Find the gapTwo requests could both read “door free” before either wrote its booking. The check lived in the app, and the database never enforced it.
  3. Fix it where it cannot be skippedA unique constraint on door and slot, an idempotency key on every booking, and a clear “taken, here are the next three” message for the carrier who loses the race.
  4. Ship with the operations manager watchingThe change was rehearsed on a Sunday behind a feature flag, then switched on at 08:00 on Monday with the whiteboard still up.
migrations/0142_dock_slot_unique.sql
-- before: availability checked in application code onlySELECT count(*) FROM bookings WHERE door_id = $1 AND slot = $2;INSERT INTO bookings (door_id, slot, carrier_id) VALUES ($1, $2, $3);ALTER TABLE bookings ADD CONSTRAINT one_truck_per_door UNIQUE (door_id, slot);INSERT INTO bookings (door_id, slot, carrier_id, request_key)  VALUES ($1, $2, $3, $4)  ON CONFLICT DO NOTHING RETURNING id;
  1. Load replay3 double bookings in 400 requests, each pair written within 40 ms of the other.
  2. EngineerA race between the check and the insert. The database now refuses the second truck, and the carrier sees the next free slots.
  3. Your operations managerApproved for Monday 08:00 after the Sunday rehearsal.

Sectors

Questions about custom software

Do we need a finished specification?

No. An idea and a clear user are enough. Scoping is part of the work, and we turn the idea into a short list of features for the first version.

Can you take over software someone else built?

Yes. We review the existing code first and tell you what to keep, fix or replace before we agree any work.

Which platforms can you build games for?

Mobile, web and PC. We choose the engine that fits your game and your audience, and explain the trade-offs during scoping.

Do you build on blockchain?

Blockchain is the right tool for some problems and the wrong one for many. We decide the problem first, then build. If a normal database would serve you better, we will tell you.

Scope the first version with us

Bring the spreadsheet, the inbox or the idea. In two weeks you get the first version’s scope in writing, a price, and a prototype of the screens that matter.

Scope your buildChoose another practice