Skip to content
Talk to us

Custom software, built a few times a year.

We design and build software for other people, and choose few enough projects that each one gets a person’s full attention. Four kinds of work, what you get from each, and how a project goes from a conversation to a handover.

01 · Four kinds of work
a

A new product

You have an idea and a first set of users. We find the smallest version worth building and build it properly.

We work through the problem and the journeys that matter, settle the direction with a prototype, then design and build it: a web application (most of ours run on Laravel), a mobile app for iPhone and Android, or the website and landing pages that introduce it. The scope starts with what people need to do, so the first release has a clear purpose.

You get

  • A written brief and release scope
  • A prototype and the interface design
  • Working software and a launch plan

Start here if you need to get from an idea to something people can use.

b

Software you already have

It works, but it fights the people using it. We review it, decide with you what to change, and change it in releases you can see.

We look at how the software behaves for its users and for the people maintaining it. Then we prioritise: a difficult journey, an unreliable integration, a missing capability, or a gradual rebuild that respects day-to-day operations.

You get

  • A product and code review
  • A prioritised plan
  • Redesigned flows and tested releases

Start here if your team has outgrown a tool or your product needs its next step.

c

The work between your tools

Information moves by retyping. We connect the systems, automate the handoff, and keep a person in charge of what matters.

We build internal tools and integrations around the way your business actually runs. That might mean connecting two systems, automating a handoff, or using AI for documents and routine tasks, with review where it matters.

You get

  • A map of the workflow and its integrations
  • Internal tools or connected systems
  • Documentation and review controls

Start here if repeated data entry and manual follow-ups are slowing the team down.

d

AI in the work you already do

AI is good at reading, sorting and drafting, and bad at being responsible. We put it where it saves hours and keep a person on the decision.

We find the steps in your workflow where a model can read documents, draft replies, classify requests or summarise records, and build that into the software your team already uses. Every output gets a check: a range, a rule, or a person who approves it before anything leaves. It is the idea behind our own products: think first, then wait for you.

You get

  • A short study of where AI helps and where it does not
  • An AI integration with review and audit controls
  • A trial on your own data before rollout

Start here if you want AI in your business without handing it the keys.

02 · Four stages

How a project goes.

We agree the scope, the deliverables and the review points before each stage begins. You can start with one focused piece of work.

  1. A written brief

    Understand

    We look at the work as it is done today, talk to the people doing it, and agree which problem is worth solving first.

  2. A plan and a price

    Decide

    Scope, design direction, cost and review points, in writing. A prototype can settle the hard questions before anything is built.

    ← Your decision

  3. Working software

    Build

    Design and engineering move together. You see working software at each review and shape the next release.

  4. A handover

    Launch and support

    Release, documentation and access for your team. Support and improvements follow the plan we agreed.

03 · Questions

Questions people ask first.

You do not need a finished specification to start.

Can we start before the brief is finished?
Yes. Bring the problem, the people it affects, and whatever you know so far. The first stage turns that into a scope and a decision about what to build first.
Can you work on software we already have?
Yes. We start by reviewing the product, its code, and the way your team uses it. Then we decide together whether to improve parts of it, plan a gradual rebuild, or work alongside your existing team.
What does a project cost, and how long does it take?
Both depend on the scope, the integrations, and what is already in place. We agree the cost and schedule before each stage begins. If discovery is needed first, it has its own price, and you decide on the build afterwards.
Who owns the code?
Ownership of custom code, account access, and handover are set out in the project agreement. We also list any third-party services and open-source licences, so you know what you receive and what has separate terms.
What happens after launch?
We plan the handover and support before launch: documentation, responsibility for hosting, and how fixes are handled. Ongoing maintenance and improvements are scoped around what your team needs.
Do you build custom software outside schools and laboratories?
Yes. klasmint and sahireport show how we think, but client work can be in any field where people still retype, reconcile or chase information by hand. We start by looking at how the work is actually done.
What do you build, and with what?
Web applications, mobile apps for iPhone and Android, websites and landing pages, integrations between systems, and AI features including real-time voice assistants. Most of our web applications are built with Laravel. We choose tools your next developer will recognise, and say why.
Can you add AI to software we already use?
Usually, yes. We look for the steps where a model can read, sort or draft reliably, connect it to your existing software, and add a check on every output: a rule, a range, or a person who approves it before anything is sent or saved.
Does every project need AI?
No. Often an integration, a simpler workflow, or a conventional feature solves the problem better. Where AI is useful, we agree how its output is checked and where a person stays in control.