We build products for ourselves before anyone else. This is where our ideas take shape — and where we find out which ones do not work.
How an internal experiment becomes something a client can rely on.
We build to solve our own pain points.
If it proves useful internally, it graduates.
Clients start ahead, not from zero.
The delivery tool we wanted and could not find in one place: a client raises a ticket, the thread stays attached to the work, and the task lands on an engineer with a date on it.
Client requests arrive over email, WhatsApp and calls. They get re-typed into a task board, lose their context on the way, and nobody can answer "where is this" without asking three people.
A client-facing ticket intake with threaded communication per project, feeding a scheduling and assignment board on our side. One record from request to shipped, visible to both ends.
Ticket intake, per-project threads, task assignment and scheduling, capacity across engagements, and time logged against the ticket that caused the work.
Most studios and agencies have this problem. We are building it for our own delivery first; if it survives real client pressure, it is the clearest candidate we have for an external product.
Tools we built because the alternative was doing the work by hand. Split by whether they have earned a place in our week yet.
Deployed and used on live work today.
Our internal starter template for spinning up new projects fast. Pre-configured auth, database, deployment pipelines, and design system. The foundation we use for every new project, packaged for reuse.
Ruby on Rails, Postgres, Docker, Next.js
Being dogfooded now. They graduate only if they survive real use.
Real-time health dashboard for distributed systems. Aggregates logs, metrics, and uptime across our internal tools into a single view, so nobody has to tab-hop to find out whether something is on fire.
Ruby on Rails, Postgres, Action Cable, Next.js
One page per project holding everything a client needs to take the code and run it themselves: repository links, a runbook, the environment variables, deploy steps and where the credentials live. We hand the codebase over anyway — this makes the handover something you can read rather than a zip file and good luck.
Ruby on Rails, Postgres
AI-assisted specification writer. Feed it a product idea, get back structured PRDs, user stories, and technical requirements. Built to remove the blank-page problem from product planning.
Ruby on Rails, LLM APIs, Next.js
Scheduling for distributed teams that respects focus blocks instead of filling every gap. Proposes meeting windows across time zones; a person still confirms them.
Ruby on Rails, Postgres, Calendar APIs
What we shut down, and what it taught us. Every studio has these; most do not publish them.
We tried to build an autonomous AI agent for client communication and task management. Hallucination rates were unacceptable for production use — clients received inaccurate project updates and incorrect scheduling information. The trust cost was too high.
AI agents need a human in the loop for anything client-facing. We use AI for drafting and suggestions; a person reviews and sends. That rule now governs AuroraSpec and TimeSync: the model drafts, a person decides.
Clients do not start from scratch. Every build begins from the templates, auth patterns and deployment pipelines that already run our own tools.
Authentication patterns validated across multiple projects. Clerk, NextAuth, custom JWT — we have shipped them all.
Prompt design, retrieval pipelines, evaluation harnesses. Patterns refined through real production use, including the ones that failed.
CI/CD, preview environments, monitoring. Infrastructure-as-code templates ready to clone.