smallbox

← All work

Case study

Knowledge assistant for work instructions

The idea

In a hospital department, the instruction for a task almost always exists: in a document system, a shared drive, a binder by the machine. The gap is between the instruction existing and a colleague finding it at the moment it is needed. The founder saw that gap from the inside. His idea: ask in your own words, get the instruction back, and let the people who own the instructions see what their colleagues could not find.

He built a prototype himself, with an AI assistant, over five weeks in the summer of 2026. It answered questions from the department's own documents with the sources cited, and it carried a rule worth keeping: who may read what is decided by the search itself, never by asking the model to behave.

Smallbox built the product with him from there. The idea and the knowledge of the field are his; he owns the product, and Jack is its co-owner.

A prototype is not yet a product

The prototype did what a prototype is for: it proved the idea, and it showed the next problems.

  • The search index lived in memory, so every start rebuilt it: about ninety minutes, later cut down with a cache.
  • Who could read what followed the names of folders, so one typo in a name opened a folder to everyone.
  • Nobody signed in. A person's role travelled with each request, as the prototype itself noted.

None of this is a mistake in a prototype. It is the point where an idea needs a structure: an owner for each kind of data, a real sign-in, and a way to change one part without disturbing the rest.

Understanding before building

Before any code, the idea was worked through with the founder until it could be drawn as a system, with the business it serves written into it.

Who uses it: a colleague with a question, a manager who owns the instructions, an administrator who connects the sources. What makes it worth paying for: every question is written down, answered or not, so the manager sees where the instructions fail and fixes them where they live, and the next import brings the fix in. How it is delivered: hosted, or on the customer's own server, because some customers cannot let their documents leave the building. The prices and terms followed in the first days of the build, written down as a proposal to be changed, and the founder has since changed parts of it himself.

The system was drawn in two days and twenty-four versions, argued through with two AI assistants, before the first line of code:

The design, drawn before the first line of code: each box owns one kind of data, each line is one call between two boxes, and each store is marked precious or rebuildable.

Each box is a responsibility with one owner. Each line is one call between two boxes. Each store is marked as precious (the original documents) or derived and rebuildable (the search index). The reason for every boundary is on the record: the same product has to survive two ways of being delivered. The phone and AI-client apps at the top left were dropped on the second day of building, because a phone at the machine opens the website.

The drawing is interactive, with every box and line explained: the knowledge assistant's architecture, box by box.

Eleven days of building

The repository started on 15 September 2026 with nothing in it but a test collection; no code was taken from the prototype. By the second day the product ran on the founder's own server, under his own domain. On the eleventh it was handed over.

How it was built is the part that transfers:

  • A plan before each piece: what will be built, what changes, how it will be tested, and afterwards a log of what building it found. There are 105 of them.
  • The drawing as the contract. A test reads the code's imports and fails the build when one part reaches into another part's data. Each of its rules was first broken on purpose, to prove the test notices.
  • Measured before decided. Search was measured on a made-up collection of 57 documents and 136 questions before any real document arrived, then on 23 of the founder's real documents: for 98 of every 100 answerable questions, the passage that answers it was among the top results. That figure says nothing about how well it says "not found"; that is measured on its own.
  • Decisions written down with who made them and why, 186 of them, so a change of mind has something to change.

Along the way: running on the server on the second day; real mail, a test payment end to end and a backup restored table for table on the fifth; the first real cloud source on the sixth; and on the last day, five installations from scratch on a separate machine, the way a customer would install it, with 17 findings fixed.

What the founder has now

  • For a colleague: ask in your own words; get the matching instructions and an answer written only from them, in your language. When nothing matches, it says so, and tells "missing everywhere" apart from "there, but not for you".
  • For the manager: every question and what happened to it, the notes colleagues leave, the subjects no instruction covers, and a direct way to fix an instruction where it lives.
  • For the administrator: documents from Google Drive, Dropbox, Microsoft, a folder or the organisation's own system; users and groups, by hand or from Microsoft's directory; Danish and English; whose AI key is used.
  • For the business: sign-up, trial and subscriptions; licence keys and a portal for customers who run it themselves; a console for the owners that sees counts and states, never a question or a document.
  • For whoever comes next: over 1,100 tests that run on every change, a release started by hand, nightly backups, and a written map of the whole system that loads in every AI session.

Technically: Python with FastAPI, PostgreSQL with pgvector, a multilingual embedding model that runs on the server itself, and Next.js for the web. One repository of modules with one database schema each, released as two images; the same release runs hosted and on a customer's server.

The week after

On 25 September the founder started working on it himself, in his own AI sessions, with the plans, the tests and the map in the repository to keep the work on its rails. In the week that followed he put new versions on the server, published a user guide, built a subscription page, and made a launch film for the product's website. His larger plans still come to Jack to read first; the daily work no longer waits for anyone.

The founder is moving the product forward, building on the foundation we created and our continuing collaboration.

What is not done

  • No customer has paid. Payments have run end to end, but only in Stripe's test mode.
  • It has not been used in daily work yet. The pilot is the next step.
  • The business side was built ahead of the first customer, on purpose, so there is something concrete to change. The founder has already started changing it.
  • The Microsoft sources are built and not yet proven against a real Microsoft account.
  • How people actually want to use it is not known until they do. That is the next thing to learn, from users rather than from new features.

What this shows

If you hold an idea you understand better than anyone, or a prototype that proved it, or a business running on tools that do not quite fit it, the missing piece is usually not more features. It is someone who sits with you until the idea is a system, builds that system so it holds together, deploys it, and leaves you able to go on. That is what was delivered here: not a finished product, but a substantial one, running, with its business written down and its next steps open.

If you are starting from an idea or a prototype of your own, this is the shape Prototype to Product delivers.

Want your product in this shape?

← All work