We spent six months turning a personal workaround into something worth inviting people to try
Six months ago Melororium was a single workspace with the basics: tasks, time tracking, client records, invoicing. It worked for the three of us. It was not something I would have asked anyone else to run their team on.
That changed this week. We opened it up for anyone who wants to test it, and I want to walk through why it took six months to get here instead of six weeks.
The first real gap showed up in week three. I blew past a client budget by roughly three weeks of work before anyone noticed, because nobody was watching the number until invoice time. Not a bug, a blind spot. I had built a tool that tracked what happened, not one that warned you before it happened.
That became Budget Guardian: set a budget on a project, get warned at 80% of the cap instead of finding out at the invoice. Invoice Generator turns logged hours straight into a PDF with payment status attached, and Invoice Tracking follows each one through sent, viewed, paid, and overdue, so nothing quietly sits unpaid for a month before anyone checks.
Deadlines had the same problem from a different angle. We kept finding out a task had slipped the day after it slipped, usually from a client asking where something was. Project Alerts closes that gap now: six alert types, bottlenecks, deadline risk, budget warnings, overdue escalation, idle projects, and a morning digest, landing in Slack, email, or the inbox inside the app.
Recurring Projects clones a project on a schedule, so nobody rebuilds it from a stale template every time a retainer client's month resets. Smart Templates does something similar for one-off launches: start from a saved board structure and every deadline re-maps itself from the real start date, not the date the template was built two months ago.
Clients needed a way in that was not email. Proposals turned into one of the pieces we use the most: a client accepts through a public link, no account needed on their end, and it converts straight into a live project. No re-entering scope that already got signed off in a document somewhere else. Public Status Page answers the other half of that: a read-only link clients check themselves, no login, so the "quick update?" email at 6pm on a Friday stops showing up at all.
The team side needed work too. Smart Onboarding builds a role-based checklist the moment someone new joins, because our own second hire spent her first morning asking three different people what she was supposed to be doing. Remote Team Scheduler puts each person's local time on their own tasks, since half our early testers are spread across three time zones and kept scheduling calls half the team was asleep for. Backup & History gives us a one-click export of the whole workspace, plus the ability to roll a task description back to an earlier version when someone asks what it used to say before it got edited three times.
None of that is finished, and I do not want to pretend it is. Client Portal, a branded space where clients see their own project without us building them a status page by hand, sits around 39% done. An AI assistant that turns a rough task description into a structured plan is at a similar stage. A real chat layer inside tasks is further along, close to half done, and multi-currency recurring invoicing is in the same range. We are not shipping any of those as ready. They are what comes next.
Pricing did not move through any of this. One price for the whole team, whether that is 4 people or 25, not a per-seat charge that climbs every time someone new joins. It kept the roadmap honest in a way I did not expect going in: there is no seat count to gate a feature behind, so nothing gets held back to justify a higher tier.
So here is the actual news, past all the feature names above: the demo is open. Not a waitlist, not a beta form that goes nowhere. If you run a small team and want to see whether six months of fixing our own blind spots turns out useful for yours, no card required:
What's the one operational thing your team still does by hand that you wish ran itself?
I like how the features came directly from problems you actually experienced instead of being added just to make the product look bigger. The budget warning and client status page especially feel like they solve problems that are easy to overlook until they become painful.
Budget Guardian is the only thing on that list I would put on the homepage. I ran a services business for almost twenty years, and the pain that actually made owners rip out a tool was never task management, it was finding out a project went underwater after the work was already delivered. The rest of what you shipped is table stakes against Harvest and Productive, so lead with the one feature that protects margin and let people find the other nine after they are already inside.
Love the approach of building to fix your own blind spots first. The 'Budget Guardian' feature hits close to home—we've all blown past client budgets before realizing it.
I especially respect the flat-rate pricing model. Per-seat pricing always creates friction for small agencies when they need to add temporary freelancers to a project.
Out of curiosity, how do you plan to handle the infrastructure costs if a team scales to 50+ or 100+ users on the flat rate? Is there a hard cap or a 'fair use' policy?
Congrats on opening the demo, the feature set looks really solid for 6 months of work.
The eighty percent warning is the right feature and its whole future depends on what it compares against. Eighty percent of budget spent on a project that is also eighty percent delivered is not a problem, and if the alert fires there anyway people mute it after the second time and you are back to finding out at invoice. What makes it trustworthy is comparing spend to progress rather than to the cap alone, even something rough like hours logged against tasks closed. Otherwise the feature built to remove a blind spot becomes another notification people learn to dismiss.
What stood out to me is the distinction between tracking what happened and actually preventing the problem in the first place. The 80% budget warning is a good example of turning a painful personal experience into a useful workflow rather than just adding another reporting feature.
I also like that you’re openly showing what’s still unfinished. That makes the six-month journey feel much more realistic than presenting everything as “launch ready.”
I’m curious which feature early users end up relying on most consistently once they’ve had a few weeks with the product.
The part about building around “blind spots” rather than just adding more tracking really stood out to me. There’s a big difference between a tool telling you what already happened and a tool helping you notice something before it becomes a problem.
I also like that you’re being explicit about what isn’t ready yet. Six months of development can easily turn into a giant feature list where everything sounds finished, so showing what’s still at 39% or 50% makes the launch feel much more grounded. Curious to see which of these features ends up becoming the one people use in ways you didn’t originally expect.
The breadth is clear, but which workflow are early testers repeatedly relying on enough to make Melororium part of their normal process?
The week three thing stuck with me. You had time tracking and still blew the budget by about three weeks because nobody looked until the invoice. The 80% warning is the part that actually changes the job. Public status page so the Friday 6pm "quick update?" email dies is the other half I kept nodding at. Did clients actually stop writing, or do they still email and then glance at the link?
Six months is the real validation — most quit at month 2. The pivot from personal tool to invite-only means you found acute pain, not polite interest. That's the signal that compounds.