galenry.Get the foundations right before customers arrive
Features are rarely what sinks a subscription product. Keeping customers apart, billing and the path from trial to paid are, and they are hard to fix once real customers are on the system.
The shape of the work
Agreed before we start. You own everything we produce, whether or not you continue with us.
- Starts with
- Product or platform review
- You get
- A platform for many customers
You are probably here because of one of these. Each one points to where we’d start.
- 01
What you are seeing
Customer separation that relies only on application code
The question it raises
Are we certain one customer cannot see another’s data?
Where we’d start
- Customer separation enforced in the database
- 02
What you are seeing
A pricing change that needs an engineering project
The question it raises
Can we change pricing without a migration?
Where we’d start
- Usage recorded separately from price
- 03
What you are seeing
Trials that sign up and never return
The question it raises
Where exactly do trials stop converting?
Where we’d start
- Onboarding measured at each step
- 04
What you are seeing
Releases that go to everyone at once, or not at all
The question it raises
How do we ship to some customers before all of them?
Where we’d start
- Releases behind flags, to a small group first
None of these sound right? Tell us what is actually happening.
Describe the problemThe parts that are expensive to fix later. Not all four land in every engagement.
Customer data kept apart
Separation is enforced below the application, so a mistake in feature code can’t show one customer another’s data. On Postgres we usually use row-level security; the principle matters more than the tool.
Usage recorded apart from price
Usage is saved as events and priced afterwards, so changing a plan or adding a tier doesn’t need a data migration.
Onboarding measured at each step
Tracked from sign-up to first real result, so you can see which step loses trials instead of guessing.
Releases behind a switch
New features go to a small group first. A bad release is switched off in seconds, rather than rolled back under pressure.
How the engagement runs. The shape holds; the depth of each phase moves with the problem.
Settle the model
Customer separation, roles and the billing model are settled before code, because they are expensive to reverse once customers are live.
You get
Data model + separation design
Build the base
Separation, sign-in, usage tracking and feature switches, built as the base every feature sits on.
You get
Working platform
Build the product
The features customers actually pay for, with onboarding tracked from the first release rather than added later.
You get
Shipped product + analytics
Run it
Support tools, a view of usage, and a runbook for when a customer reports something odd.
You get
Support tools + runbook
What we can point at. Including where we cannot.
Two subscription products we build and operate ourselves
Customer Support and Travel Assistant: we are our own first customer for this practice
See itNo third-party SaaS platform delivered for a client yet
Our experience here is running our own. That is a real limitation and we would rather you hear it now.
What we reach for first. Not the only things we work with, and we change them when there is a reason.
Platform
Customer separation enforced in the database, below the application code.
- Next.js
- Node
- Postgres RLS
Billing
Usage recorded separately from price, so a plan can change without a migration.
- Stripe
- Usage metering
- Plan limits
Access
What larger customers ask for first, built in rather than added for the first big deal.
- SSO
- Roles
- Audit logs
Release
New work reaches a small group first, and can be switched off in seconds.
- Feature flags
- Cohorts
- Product analytics
Tell us what you’re trying to build. We’ll tell you where we’d start.
Bring an idea, a stalled project, or a system that has outgrown itself.
Send us a brief
The problem, what you have tried, and what success looks like. A few lines is enough to start.
Prefer email? contact@galenry.com
What happens next
- 01Reply within one business dayFrom one of our engineers.
- 02First call: 30 minutes, no deckA working call about the problem. We ask questions rather than present slides.
- 03An honest answerWhere we would start, or, if we are not the right team, who might be.