How We Build Phoveus Lab: Free, Open Source AI Products on a Shared Hub

By Tanbir Hossain Ramim. Project page: Phoveus Lab. Live product: admissionops.com.

Phoveus Lab is a small group of us building AI products around one question: what is still harder than it needs to be? Everything we ship is free and open source. Nobody takes a title, and none of it is a company. We do it in our own time because we think useful software should not be gated behind a price.

The first product out is Admission OPS. This post is about why we picked that problem, how the product approaches it, and the one structural decision that shapes everything else in the lab.

Why university admissions

Applying to university looks like an academic problem. In practice it is a logistics problem wearing the costume of an academic one.

Requirements differ per institution. Deadlines are scattered across a dozen portals. Documents get re-requested in slightly different formats. And the cost of missing one line item is not a warning, it is a lost year.

Most people run all of this out of a spreadsheet and forty browser tabs. The work is not intellectually hard. It is relentless and unforgiving, which is exactly the shape of task that should be handed to a machine. When we asked what was still harder than it needed to be, this was the easiest answer to agree on.

What Admission OPS does

The product is built around four jobs.

Parse. Documents, deadlines and requirements are parsed automatically instead of copied by hand into a spreadsheet. This is where the language models do most of their work: turning unstructured requirement pages and documents into something a program can reason about.

Track. Every milestone for every application lives on one timeline. The point is not just to store dates, it is to put them in one place, because the failure mode of forty tabs is that the deadline you missed was in the tab you did not open.

Surface the next action. The timeline is not passive. Admission OPS surfaces the next thing to do before it becomes urgent. That is the difference between a calendar and an assistant: one tells you what is due, the other tells you what to start.

Reason over a real profile. Given an applicant's actual profile, it suggests where to apply and what to strengthen. And it gives the applicant, plus everyone helping them, a single view of where each application stands.

That last part matters more than it sounds. Applicants are rarely the only people involved, and a shared view means everyone helping can see the same state instead of asking for updates.

The stack

The lab works in Next.js and TypeScript for the product surface, Python for the model-facing work, Postgres for data, and an LLM orchestration layer between them.

That split follows the work: TypeScript where people interact with the product, Python where the model work happens.

Hub and spokes

The decision I think about most is not inside Admission OPS at all. It is how the lab itself is organised.

We run it as a hub with spokes. The hub holds the things every AI product needs and nobody wants to build twice:

• Model infrastructure. The shared layer every product uses to work with language models.
• Evaluation tooling. For checking that a change to a prompt or a model made things better rather than just different.
• The design system. So every product looks and behaves like it came from the same place.
• Data pipelines. Getting data in, cleaned and into a shape the products can use.

Each product is a spoke. It brings the domain, the specific problem, the UI for that problem, and it borrows everything else from the hub.

The reason is simple arithmetic for a group working in its own time. If every new product starts from an empty repository, most of the effort goes into rebuilding plumbing, and the second product takes as long as the first. With a hub, each new product starts where the last one finished. Evaluation tooling built for Admission OPS, for example, lives in the hub, not inside Admission OPS.

It also changes what "done" means for infrastructure work. Improving the evaluation tooling is not a detour away from a product, it is an investment in every product after it. That makes the unglamorous work much easier to justify.

Evaluation as a first-class piece

I want to single out evaluation, because it is the part of AI products that is easiest to skip.

A product like Admission OPS depends on models reading documents and requirements correctly. When the output is a missed deadline or a wrong requirement, "it looked fine when I tried it" is not good enough. Putting evaluation tooling in the hub, next to the model infrastructure rather than as an afterthought, is how we make checking changes the default instead of a special effort.

Free and open source, permanently

The last structural decision is the simplest to state. Everything the lab ships is free and open source, permanently.

That is partly a value and partly a constraint that keeps us honest. With no pricing page, there is no incentive to hide the useful parts behind a paywall or to build features that exist to upsell. The only reason to build something is that it makes a hard thing easier.

What is next

Admission OPS is live, and more is incubating. The hub is what makes that realistic for a few people working in their own time: every product we finish should make the next one cheaper to start.

You can try the first product at admissionops.com, and read a summary of the lab on the Phoveus Lab project page.