Nece Labs · a software laboratory

Software nobody has a template for.

Nece Labs designs and engineers products, platforms, and AI-enabled systems for ambitious teams. We take the problems that don't fit an off-the-shelf answer and turn them into software that works on a Tuesday.

Erlenmeyer flask A glass flask that tilts toward your cursor while the liquid inside stays level.

Services

Three kinds of work. One way of working.

Design and engineering in the same room, real data as early as we can get it, and a bias toward the version that can actually be run.

Product engineering

Products people come back to

From first sketch to something a team relies on. We design the interface, build the system behind it, and stay for the awkward second version.

  • Web and mobile products
  • Design systems and interfaces
  • APIs and data models

AI-enabled software

Models as components, not magic

We build systems that use models where they help, measure where they don't, and keep a person in the loop wherever the cost of being wrong is real.

  • Retrieval, agents, and routing
  • Evaluation harnesses
  • Fine-tuning and cost control

Technical platforms

The floor other teams build on

Pipelines, internal tools, integrations, and the unglamorous reliability that makes a bold product possible in the first place.

  • Data pipelines and warehouses
  • Internal tooling
  • Integrations and observability

Bench notes

Every project starts as an experiment. Every experiment has to ship.

experiment.ts not an SDK — how we think
// A Nece project, written down before it is built.
const experiment = lab.frame({
  question: "Can support triage run without a queue?",
  success:  { latency: "< 2s", humans: "in the loop" },
});

const build = await experiment.build({
  model:    "small, fine-tuned",
  fallback: "a person, every time",
});

build.ship({
  to:    "production",
  watch: ["cost", "accuracy", "regret"],
});
  1. The question comes first

    We write down what would count as success before we write code. If we can't state it, we're not ready to build it.

  2. A person is a valid fallback

    A small, fine-tuned model with a human behind it is a design decision, not a compromise. It's usually cheaper and always more honest.

  3. Watch the strange metric

    Cost and accuracy are obvious. Regret — how often someone overrides the system — tells you whether it's actually trusted.

Selected work

Odd problems, working software.

A few recent experiments that made it to production. Described by what they do, not who they're for.

Triage engine for a support organisation

AI-enabled software · Product

An inbox that reads every ticket, drafts a reply, and knows when to hand it to a person. We built the evaluation harness before the interface, so the team could see exactly where the model was wrong before anyone had to trust it.

  • Retrieval over policy docs
  • Human-override loop
  • Per-ticket cost ceiling

Field data platform for an agricultural operator

Technical platform · Data

Sensor, satellite, and machinery data from every field they farm, reconciled into a single model a farm manager can argue with. The interesting part wasn't the dashboard; it was agreeing on what a "field" is.

  • Streaming ingestion
  • Geospatial model
  • Offline-first field app

Pricing simulator for a logistics marketplace

Product engineering · Simulation

A what-if tool that replays a real week of demand under new pricing rules before anyone touches production. Ops can break pricing safely, on a Friday, and see what it would have cost.

  • Deterministic replay engine
  • Rule editor with diffs
  • Scenario comparison

Process

Frame. Build. Ship.

Three steps, in this order, because the order is the point. You can't build what you haven't framed, and you haven't shipped until it runs without us.

  1. Frame

    We turn a vague ambition into a question that can be tested. Research, sketches, and throwaway prototypes — usually a few weeks, never a slide deck.

    You get

    • A written brief with a definition of success
    • A prototype you can put in front of real people
    • A clear go / no-go decision
  2. Build

    Small team, weekly releases, real data as early as possible. Design and engineering happen at the same bench, not in sequence.

    You get

    • Working software every week
    • An evaluation suite that grows with the product
    • Documentation written as we go
  3. Ship

    Launch is a step, not the finish. We instrument, watch, and iterate until it runs without us — then hand it over properly.

    You get

    • A production system with monitoring
    • Runbooks and a handover your team can use
    • A clean exit, or a long relationship — your call

Contact

Bring us the problem nobody else wants.

Tell us what you're trying to build and what's in the way. We'll tell you plainly whether we're the right lab for it.