About

The spreadsheets were the system.

I worked somewhere that ran real product development on spreadsheets and a shared drive. Not because anyone thought it was a good idea, but because the tools that fix it are priced and shaped for companies with a procurement department. Everyone knew which file was wrong. Nobody could say which one was right.

Who is building it

I'm Row. I started ManyRows in 2025 and I build and run it on my own, bootstrapped, with no investors.

The name works three ways, which was mostly an accident. The literal one is rows of data, because that is what the product is made of. The truest one is relational: one to many. A parent to its components, a style to its colourways, an order to its sizes. That one-to-many edge is the thing a spreadsheet cannot hold on to, and holding on to it is most of what a PLM is for. The last one is that I'm Row, and there is exactly one of me doing many things: schema design, the billing integration, support, this sentence.

Before this I spent years building content platforms and app builders, so I already had the hard part: a data model that bends to a garment, a formula and a machined part without falling apart.

The obvious move with an engine like that is to point it at another generic app builder. I wasn't interested. There are plenty of those, they all demo beautifully, and not one of them would have helped the team I actually watched struggle, because the work was never “store some rows” and always “which revision did the factory build, and who approved it”. A tool that can model anything leaves you to invent change control, revisions and a bill of materials yourself, which is the entire job.

So this is a PLM, not a database with a good interface. You define the types and the fields, but what sits under them knows what a multi-level bill of materials is, what a size spec with grading is, and what a change request has to guarantee when two people edit the same record. Solving one problem I had seen properly was worth more than solving every problem shallowly.

It is a real product with paying plans, not a side project looking for a direction. It is also, honestly, small. Both are true and you should weigh them together.

What one person buys you

Being small is usually written up as something to apologise for. In this category it is the reason four specific things on this site are possible at all.

Pricing on a page, not in a quote There is no sales team to feed, so there is no reason to make you book a call to learn what it costs. Every plan and limit is on the pricing page and you can work out your bill unaided.

Your gap can become the roadmap Custom development is free on Pro and above, within reason, because one person can actually ship it. When the gap is something ManyRows should have had anyway it goes to every customer rather than sitting in a branch for you. The limit is honest too: no one-offs only you would use, and you get that answer in a sentence.

Comparisons that sometimes say buy the other one Every competitor page names the cases where that product is the better answer, because there is no quota that makes it costly to say so. If Arena or Oracle or Propel fits you better, the fastest way to find out should be our own website.

No roadmap by committee Features get built because a real product needed them, not because a competitor announced one. That is why the toolkit is deep in odd places, like size specs with grading and formulas with co-products, and deliberately absent in others.

And what you should ask about

The fair question about a one-person company holding your product data is what happens if I stop. You should ask it, and you should ask the funded vendors a version of it too, because “we get acquired and the product is sunset” is a real thing that happens in PLM.

My answer is that your exit is built in and you can test it today. The whole project exports as a bundle you can re-import somewhere else, the schema as well as the records, over the same API you use every day. Not a CSV of rows with the model thrown away. No support ticket, no retention call. If ManyRows stops being the right answer, for any reason, you leave with the thing you built.

That is deliberate. I would rather compete on whether the product is good than on how painful it is to leave.

Start free Take the tour Talk to me