Try it at app.perennial.design with
demo@perennial.designandPerennialDemo1.
Problem
After a year consulting for small studios, every engagement ended in the same place: good work and chaotic operations. I interviewed more than a dozen practitioners, from furniture designers to ceramicists to public artists, and heard the same story each time. Plans lived in a notes app, clients in a spreadsheet, and invoicing in a service of its own.
The tools that exist sit at two extremes. Salesforce is built for sales teams and feels absurd at studio scale. Notion hands you raw blocks and leaves the system design to you, which is exactly the work a maker wants to hand off.
How might we give a one-person studio the operations of a high functioning business, without asking them to become an operations person?
Solution
One connected model.
A client connects to their projects. Projects roll up time and expenses, which become invoice lines, which reconcile against the real bank feed. Every screen reads from that one model, so every screen tells the same story.
Every record opens onto a canvas
Projects, contacts, and organizations each open onto their own canvas, with the structured fields alongside. Makers think spatially, so the software opens the way a studio table does.
From tracked time to money in the bank
Invoice lines pull from tracked time and expenses, go out as a branded email with a hosted payment page, and get paid through Stripe straight into the studio's own account.
Plaid brings in the real bank feed, and a deposit that matches an open invoice gets proposed as the match.
A pleasant, knowledgeable AI assistant
Press Space on any line and Ash is there. Factual questions get answers from live data. Judgment calls, like whether a 50 percent gallery split is fair, get the real options and their tradeoffs.
A hand-written knowledge base and a research brief on each user's corner of the market keep the advice local to the practice.
Outreach and opportunities
Pipelines for press, galleries, and stockists, with a parking lot for conversations that go quiet, beside a hand-curated feed of fairs, open calls, and grants.
Beta
The beta ran through a shared Slack. A question in the channel became a conversation about what the person was actually trying to do, then a decision, then a ticket filed straight from the thread.
Process
Four moments that set the direction of the app:
1. Onboarding
In order to make a custom-feeling application for users, a comprehensive user onboarding experience is important. I weighed the options of including an assisted personal demo, making the process self serve, and how much of the onboarding phase is mandatory before viewing the application.
2. Three options for every feature
Before any code, I made 28 standalone HTML wireframes. Every feature started as three directions, annotated red for what was still undesigned and blue for decisions to revisit, and filled with real maker content, since “Walnut slab idea for gallery show” tests line length and tone in ways placeholder text can’t.
3. Modeling the studio as one graph
Building the connected studio graph was iterative. It came together as I built the MVP, and seeing the full graph as one was the largest source of pride for me. Every surface reads from one connected model: an invoice line knows which time entry produced it, and a deposit knows its invoice. Row level security on all 43 tables from day one made the database itself the permission layer, so going from one studio to many is a switch.
4. Teaching Ash to act on the user’s behalf
Most of the people Perennial serves are skeptical of AI, so the assistant had to earn its place. I shaped Ash’s behavior in three layers:
- Friendly to people who don’t use AI. Ash starts small and grows only when the user asks. Factual questions get a direct answer, and judgment calls get the real options and their tradeoffs, so the person stays the one deciding.
- Fluent in the studio’s data. Ash reads from the same connected model as every screen, so each date and dollar comes from a fresh read of the database. A hand-written knowledge base covers pricing, contracts, galleries, and cash flow, and a research brief written after onboarding covers the user’s own corner of the market.
- Active, and safe about it. Ash can take real actions across the app. Its description of what it can do is generated from that live tool registry, so its claims always match its abilities, and it names its limits plainly. Every action comes back with a link to what it created, and when a user states a preference, Ash follows it over general best practice.
Every release is gated by judged evals at 80 percent. The first version graded answers on whether they contained specific numbers and dates, which rewarded exactly the false confidence skeptics spot instantly, so I rewrote the tests to grade the behavior itself.
The Stack
Designs start in Figma. Beta testers report bugs and ideas in Slack, and I triage every one by hand before it becomes a Linear ticket, since text from users is untrusted input. Conductor runs Claude Code on several tickets at once, each in its own branch, and every pull request on GitHub gets a Vercel preview before it merges. Supabase holds the data, PostHog shows how people actually use the app, and Sentry feeds errors back into the same queue each week.
Status
Perennial is live and usable end to end: multi-tenant, documented, and waiting behind its eval gate for the next change. There are hundreds of features I’d like to implement, and am focusing my efforts on fixing bugs and talking with customers as I start to monetize the software.
Perennial was the tool I originally built for me, but quickly morphed to serve the hundreds of designers and artists I went to college with and met in my early career. I am excited to continue to build and pivot the software as new tooling makes creative development and operations more expansive.