Describe your business. Get the system that runs it.

Hi. I'm Shannon. Let me show you around RowFold. Your operation already has a shape. Customers connect to orders, orders to products, products to the people making them. Spreadsheets cut all that into pieces. RowFold keeps it whole.

So, how do you start? Describe your business in a sentence. A wholesale bakery, say. RowFold proposes the tables, the field types, and the links between them, then builds it once you say yes. Or drop in the spreadsheets you already have, and it'll find the relationships running through them.

Let's look underneath. It's a real relational model. 23 field types. Two-way relations. And rollups that travel as many hops as your question needs. Change the model later, and every view, report and automation moves with it.

You'll want to see this more than one way. One set of records, and every useful way to see them. Grid. Board. Calendar. Timeline. Even a live map of every address. Each one saved with its own filters, sorts and layout.

Reports are the part I'd use every day. Group the orders by delivery route, reaching through into the lines on them. Then drag the results straight onto a dashboard. Every figure comes from your records as they are right now.

Nothing so far has done any work for you. Mark an order packed, and the rest of the operation follows. The stock comes down. The van is booked. The customer is told. It won't let the count go negative. And every step can reach 48 connected systems.

All of that assumes the work is already in there. Publish a form anyone can fill in, no account needed. Give a table its own email address. Put a chat widget on your website. However it arrives. It lands as a numbered record wearing your branding, and every reply stays on it.

Here's the part I'd be sceptical about. Anyone can put a chatbot on a database. The hard part is knowing whether to believe it. So every figure is re-computed against your live records after the answer is written. And one click shows you the exact query it ran. And it doesn't only answer. Ask for a table, a report, a whole automation, and it builds them for you. Nothing goes in until you approve it.

Not everything should go straight in. Some records deserve a proper sign-off. Set the stages yourself: a manager, then finance. Decide how many people have to agree. Nothing moves until every linked line item is approved. Then it's posted. Sealed, and locked. Until someone unposts it and gives a reason.

I've left the unglamorous part till last. All the plumbing you'd otherwise have to negotiate for. A real API. Signed webhooks. Permissions that hold all the way through reports and AI. An audit trail. Single sign-on. Two-factor. None of it held back for a higher tier.

It's Shannon. Let's start with nothing. You describe what you run, in your own words. No template to choose. No columns to name. And if a sentence isn't enough to design from, it asks you one question.

This is the part I'd judge it on. What comes back is a model, not one big sheet. Tables that link to each other. Statuses carrying their real options. Addresses where places matter. An order number that issues itself. A total that adds itself up. And there's no approve step. Each table is in your sidebar the second it's designed.

An empty workspace tells you nothing. So it fills every table with a handful of records from your own trade. Real names. Real addresses. Dates around today. And they're linked to each other, so you can see the thing working. Delete them the moment your own arrive.

So how do you actually look at it? It reads the fields it just made and opens each table the way that table wants to be seen. A status becomes a board. A date becomes a calendar. An address becomes a map. Then one report worth checking on a Monday, and a dashboard over the top of it.

And it's built. Every table it made is an ordinary table. Rename a field. Change a type. Add the one it missed. Nothing it made is locked. Or keep describing, and it keeps building.

It's Shannon. Let's total something up. Group the bakery's orders by delivery route. The route's on the customer, not the order. It follows the link. And the money comes off the lines, a table further out again. Four routes, four totals, nothing re-typed.

A number on its own says very little. Give it a period, and something to compare against. It asks which date you mean. Ordered, shipped and paid are three different questions. Against last month you get last month entire, not the last thirty days. And the arrow says which way. Not whether that's good.

One axis is usually not enough. Routes down the side, months along the top. Every square is that sum worked out again inside it. Then filter the groups themselves. Not the orders over ten thousand. The routes that billed over ten thousand. And the totals still match what's on screen.

Now put it where you'll see it. A report goes onto a dashboard as a tile. Then click a bar. Every other tile about those same orders follows it. Six of eight narrowed. It'll tell you which two didn't, and why. Click again and it's gone. Nobody inherits your poking about.

Here's the bit I'd care about most. Every figure is one click from the records underneath it. Open the bar, and there they are, fetched again so it's true now. And where it can't be exact, it says so. Send it to someone with no login, and the columns freeze as you publish. A number you can open is a number you can argue with.

It's Shannon. Nothing's done any work yet. Not on its own. So pick the moment. An order's status becomes Packed. Or a form comes in. Or nothing happens at all, and it's simply nine in the morning. Nine where the work is. Not nine in a data centre somewhere.

Now say what happens. Take twelve loaves off the stock. Tell the customer. None of those are on the order. It follows the links and writes to the real thing at the other end. Not a message about your records. A change to them. And it refuses rather than writing stock you haven't got.

Not all of it should happen at once. A step can wait. An hour, a day, until Monday. A step can run once for every line on the order. And a step can stop, and wait for a person. Over five hundred pounds, somebody says yes first. Then it picks up exactly where it stopped.

Some of it isn't in here at all. Email the customer. Text the driver. Post to the warehouse's own software, and see what it says back. Or reach into something you already pay for. Your accounts, your shop, your chat. Every one of those is another step in the same list.

Here's what I'd want before I trusted any of it. Every run is written down. What set it off, and every step in order. What it looked at, what it wrote, what came back. If one fails halfway, it says so, and what had already happened. And it tells you, rather than letting a customer find out first. Run it by hand first, if you'd rather watch it once.

It's Shannon. Two tables, no link. Link an order to the customer who placed it. Now Harbour Deli has all nine of theirs, and you didn't build that. A link is one thing, seen from both ends.

Now borrow something from over there. Put the customer's delivery route onto the order. It isn't a copy. It's a window. Change the route on the customer, and every order shows the new one. Nothing to re-import. Nothing to go stale.

Now the other direction. Count the orders on each customer. Total what they came to. Then narrow what gets counted. Only the posted ones. Only the ones on Route B. A total that counts everything is rarely the total you wanted.

It doesn't have to be next door. The region isn't on the order, and it isn't on the customer either. It's on the area they sit in. Three tables out. Name the route once and it goes and fetches it. Conditions travel the same way. Only the orders whose customer is in the south west.

And you don't have to change the table to see it. Add the region as a column of this one view. No new field. Nobody else's screen changes. The other way is a Region column copied onto all eleven hundred orders. Which is fine until somebody moves. What you're after is usually already there. It's just somewhere else.

It's Shannon. A table isn't one shape. Same records. Show them as a grid. Or a board, by status. Or a calendar, by the day they're due. Or a map, because the address is on the property, not the booking. Nothing was copied. There is one row per booking, and there always was.

Then shape it. Filter it, sort it, hide what you don't need today. And that's the same control on every one of them. Save it, and everyone who opens it sees what you saw. Or keep it to yourself, if it's just how you like to work.

Here's what I'd want to be sure of. Every view is bounded by something it can name. A list scrolls. A calendar loads the month you're looking at. A map follows the filter. Not a hundred and twenty events out of fifteen hundred, because those were edited last. And where it still can't show you everything, it says so on the screen.

Now the one you'll work in. Freeze the columns you need to keep seeing. Drag the rest into your own order. Widths belong to the view, so it opens the same for everybody. And the totals along the bottom come from the database, over every matching record. Not the ones on screen. Those would climb as you scrolled.

Then get it out of here. Send a view to somebody with no login at all. Or subscribe to it, so the dates turn up in whatever calendar you already open. And it keeps up. Move something here and it moves there. One set of records. As many windows as the work needs.

It's Shannon. Ask it to look. It goes over the whole workspace. Counts every row you've got, and reads a sample of what's in them. That takes half a minute, so it isn't something that happens quietly on a page load. You ask. Then it goes and looks.

Here's what comes back. That text column is really dates. Those eight values repeat across four thousand records. They want to be a pick list. And Contact name, Contact email and Contact phone were always a Contacts table. Not advice in general. A short list of things it can go and do.

Don't take its word for it, though. Every card measures what it would do, before you agree to anything. Two hundred and fourteen values parse as dates. Two don't, and it shows you those two. Pulling those contacts out would make a hundred and forty records. And changing a column's type rewrites nothing at all.

Then it's yours to take or leave. Apply is one click. Say no and that one is gone for good. And it checks again every time it draws a card, and once more when you press. So anything you'd already done by hand has quietly dropped off the list.

One last thing, and it's the one I'd want. These don't sit on the schema map waiting for you. While the evidence still holds, they turn up on that table's own toolbar. Where you were working anyway. And when it can't do the thing it suggested, it says so. Which is the feature working. Not failing.

It's Shannon. Let's get a spreadsheet in. This is what a real one looks like. Two header rows. Dates in three formats. And the same customer spelled four ways. None of that has to be tidied up first.

So, drop it in. Every column is read and given a type. Text. A date. A number. A currency. You can change any of them before a single record is written.

Then, where it goes. Into a new table, or into one you already have. Columns line up by name, and anything left over is yours to map or ignore.

Now the part that saves you. Pick the column that identifies a record. It counts how many are genuinely new, and how many you already hold. The ones you hold are updated, not duplicated.

And it's in. Real records. Real types. Real links. Everything else you've seen works on it from here.