Production proof

Products We Build and Operate

Running our own software in production keeps our client work grounded in the parts that matter after a demo: reliability, billing, permissions, integrations, monitoring, and support.

Most of our work is custom software built for a specific business. We also build products of our own — partly because we think the problems are worth solving, and partly because running a product in public keeps us honest about what it actually takes to ship and maintain software people depend on.

ResearcherFlow

Accelerate your research. ResearcherFlow is an AI-first research environment for academic labs — a single place to manage literature, track experiments, plan what to do next, and write up results, with an AI assistant working alongside you at every stage.

Who it’s for

• Graduate students juggling a literature review, a thesis, and an experiment log that lives in three different places
• Professors and PIs running a lab and trying to keep track of what everyone is working on
• Scientists who want their papers, data, and results in one system instead of scattered across folders and tabs

What it does

• Literature management — add papers by DOI or URL, with metadata fetched automatically, then tag and organise them by project
• AI synthesis and planner — select a set of papers and generate a citation-backed review, or turn a hypothesis into a structured experiment plan
• Experiment tracking — log runs, outcomes, blockers, and artifacts against each experiment
• Research task board — a backlog-to-done board with priorities and due dates, so the project has a visible state
• Global search — one search across papers, tasks, notes, manuscripts, and theses
• Bring in your work — connect the tools you already use and pull your existing material in
• Clone and export — your data comes back out in Markdown, JSON, or CSV whenever you want it
• Secure by default — granular permissions over who in your lab can see and change what

Plans

What It Takes to Run in Production

We are showing you this because it is the most direct evidence we can give of what we do. Nobody handed us a spec, a budget, or a deadline — we found the problem, scoped it, built it, and now run it. It is the same work we would do for you, except none of it is hidden behind an NDA. You can go use it right now.

A demo is easy. Software that real people depend on, that takes payment, and that cannot lose their data is a different discipline. ResearcherFlow runs on:

• A Django and Next.js stack backed by PostgreSQL, with Redis and Celery running background AI jobs
• Stripe subscription billing across three tiers, with plan limits enforced in the product
• JWT authentication and granular workspace permissions — owner, editor, viewer, and per-resource sharing
• Realtime collaboration over Django Channels, with presence indicators and a polling fallback when sockets are unavailable
• A public REST API documented with OpenAPI, plus HMAC-signed outgoing webhooks so other systems can react to events
• A pip-installable Python SDK so lab equipment and scripts can push data in and consume signed events
• Integrations with Zotero, Mendeley, GitHub, Jupyter, Slack, and Microsoft Teams
• Operational tooling — Sentry error monitoring, PostHog analytics, transactional email, and Docker-based deploys
• Security and quality gates — automated dependency and security scanning, static type checking, and a test suite that has to stay green

What That Means for Your Build

Every piece of that list is something a real business system eventually needs. The specifics of your project will differ, but the hard parts rarely do:

• Billing that works — subscriptions, tiers, upgrades, and limits that hold up when money moves
• Auth and permissions — deciding precisely who can see and change what, and enforcing it everywhere
• AI that does real work — retrieval, extraction, and synthesis grounded in your actual data, not a chat box bolted onto a sidebar
• Integrations — pulling from and pushing to the tools your team already lives in
• An API other systems can call — so the tool becomes part of your stack instead of another island
• Operations — monitoring, error tracking, and deploys that do not require a person watching a terminal

We did not learn those from a course. We built them, shipped them, and maintain them every week.

If we can run a production SaaS with paid tiers, a public API, and live collaboration, we can build the internal tool that is currently a spreadsheet.

If you have a product or an internal tool of your own that needs building, that is the work we do for clients. Start a conversation and tell us what you have in mind.