We stopped trying to build for everyone. Here's what we built instead.
I've been working on Melororium ( https://melororium.com ) for the past few months — a lifetime project management workspace for small teams and agencies.
For a long time, the pitch was straightforward: "Stop paying $300/month in subscriptions. Pay once, own forever."
People got it. But something was off.
The product kept pulling in a specific direction — teams, not solo operators. The pain points that made sense were team pain points: who's working on what, how many hours did we bill this client, why don't our task manager and invoice tool talk to each other. Not "I need a better to-do list."
So we stopped fighting it and leaned in.
But then came the harder question: what does "pay once" even mean when different teams need different things?
A dev studio doesn't need social media scheduling. A creative agency doesn't need AI on every task. A 5-person consulting firm doesn't need a full ecommerce analytics module.
Traditional SaaS solves this by charging per seat — the more you grow, the more you pay, and you pay for everything whether you use it or not. That's the model we're explicitly trying to kill.
Our answer: 12 core modules in every plan (tasks, time tracking, client CRM, invoicing, financial reporting, analytics, and more) — plus add-on modules for the things only some teams need.
AI is a good example. We support Gemini, ChatGPT, and Claude — but you bring your own API key. If your team uses AI daily, connect it. If you don't, you don't pay for it being embedded in your license. The BYOK model felt right: you already have a preferred provider, probably already paying for it, why should your workspace charge you again for access to the same model?
The three tiers:
Starter — $149 once → 4 users, 12 core modules. No add-ons. For tight teams that just need the fundamentals to work.
Agency — $299 once → 10 users, 12 core modules + 5 add-on modules of your choice. You pick what your agency actually needs.
Studio — $499 once → 25 users, 12 core modules + all announced add-on modules.
No renewals. No seat tax. No "sorry, that feature is in the next tier."
What I got wrong early
I assumed the audience was anyone tired of subscriptions. That's actually a huge group. But "tired of subscriptions" isn't a product — it's a mood.
The real insight was narrower: teams of 4–25 people who are paying per-seat SaaS tax that grows every time they hire someone new. That's where the math breaks hardest, and that's where paying once actually changes how the business works.
A 10-person agency on ClickUp is paying $1,440/year. Switching to Melororium is $299 once. The Agency plan pays for itself in under 3 months.
We're pre-launch, collecting waitlist now. Founding price closes July 30.
If you run a small agency or studio: what's the one module you'd actually add if you could build your own stack? Genuinely curious — it helps me prioritize the add-on roadmap.
This really hits home. As an agency owner at Mobiwolf, the 'per-seat' tax is exactly what makes scaling a nightmare—it feels like you're being penalized for growth just when you should be celebrating it. The 'Bring Your Own Key' (BYOK) model for AI is a brilliant touch; it cuts out the middleman markup and lets us use the models we’re already paying for.
To your question about modules: if I could add one thing to this stack, it would be a Resource Allocation/Capacity Planner. Most PM tools track tasks, but they suck at showing who is actually available next week across multiple projects. If you could visualize team bandwidth alongside the financial reporting, you’d have a 'killer' suite for small agencies.
Wishing you luck with the launch—moving from 'selling a mood' to 'solving a specific math problem' is the smartest pivot you could have made.
The Resource Allocation angle is something I've been thinking about
too — you're right that most PM tools show you what's assigned,
not who actually has capacity next week. The gap between "task
exists" and "person can realistically take it" is where most
agency scheduling falls apart.
It's on the roadmap. The way I'm thinking about it: once you have
time tracking data across projects, capacity planning is just
that same data read backwards — from "what happened" to
"what can happen next." The financial reporting layer makes it
more useful because you can tie availability to billing rate.
And yes — "selling a mood" was exactly the problem with the
first version. Good way to put it.
That 'capacity gap' is exactly where agency margins go to die. At Mobiwolf, we learned that 'availability' is a vanity metric unless it's tied to velocity and billing data. Reading time-tracking data backwards is clever—it turns a historical record into a predictive tool. Are you planning to add a 'buffer' or 'risk' factor to that capacity planning, or keeping it strictly data-driven? Even perfect math usually hits a wall when a dev gets sick or a scope creep hits.