Why we don't make you log into a dashboard

By Michael Wu · 4 min read ·

A restaurant owner I know paid her web guy $500 last spring to change a phone number on her homepage. The work took him eleven minutes. The invoice took her a week to chase down, and by then the number had already been wrong on Google for a month. She told me the story like it was a punchline. I have heard variants of it from a dentist, a wedding photographer, and a man who runs a single-location boutique hotel. It is not a punchline. It is the shape of how small business websites actually work.

#Why dashboards became the default

The dashboard — the editor panel with the sidebar and the toolbar and the seventeen tabs — exists because the people who build website software need somewhere to put the controls. A site has a lot of configuration: pages, menus, fonts, SEO fields, redirects, embed codes, image libraries, user roles, plan settings. Engineers organize all of that the way engineers organize anything, which is by giving each thing a screen and putting the screens behind a login.

That works fine for the people who built the software. It is, in a sense, the obvious thing to build. If you have configuration, you build a configuration surface, and a configuration surface needs a place to live.

The trouble is what that pattern silently asks of the customer. It asks them to learn the software. It asks them to remember where the menu editor is, and which tab the holiday hours live on, and whether the contact form is under Pages or under Forms. It asks them to keep a second job in their head, on top of the actual job of running their business.

#What dashboards cost you

Here is the small business owner’s reality. It is Wednesday at 1:40pm. The lunch rush is still on. The tomato basil soup is sold out, and a customer just called asking whether you have it because the website said you did. The owner stands behind the counter with a phone in one hand and a bowl in the other, and she thinks: I am not going to learn a content management system right now.

So she puts the phone down and the website stays wrong until Saturday morning, when she will remember to deal with it, except on Saturday morning she will not remember to deal with it. Three weeks from now another customer will call about the soup, and we will be exactly here again.

The other version of this story is the developer version. The owner emails her web guy. The web guy has six clients and a day job. He gets to it on Friday. He sends an invoice. The phone number — or the soup, or the new hours, or the typo on the catering page — sits wrong for a week, and the owner pays $200 for the privilege.

A dashboard does not solve this. A dashboard is this. The work the owner is avoiding is not the typing. It is the cognitive overhead of opening a separate piece of software, signing in, finding the right screen, and not breaking anything adjacent.

#A different bet

When I started TaiChu Web AI, I wanted to see what would happen if we just did not build the dashboard. Not as a UX flourish — as a real structural decision. No admin panel. No CMS to learn. No tabs.

What replaced it is the thing the owner was going to do anyway, which is send a message. You write what you want changed, in the same plain language you would use texting a friend. “Change Tuesday lunch hours to 4pm to 9pm. The tomato basil soup is sold out today.” We make the change. You see it as a preview before anything goes live — that part matters, and I will come back to it — and if it looks right, you publish with one tap. If it looks wrong, you say so, and we fix it.

The preview is the answer to the reasonable next question, which is: what happens if the AI gets it wrong? Nothing public happens. Every change waits for you to look at it. The site that visitors see does not move until you say it moves. This is not a feature we bolt on; it is how the workflow is shaped.

I will not pretend this was the easy thing to build. Treating each customer’s website as a set of versioned files with a guarded review step is more work than putting a text editor behind a login. We picked the harder build because it is the easier use. The owner’s job is to run the restaurant. Our job is to make the website behave like the restaurant — current, accurate, alive — without asking her to learn anything new. How this works in practice covers the steps in more detail.

#What we won’t do

We are not a website builder. If you do not have a site yet and you want to design one from scratch, we are not the tool for you — pick a builder you like, get something up, and come back to us when keeping it current starts to feel like a tax.

We are not a hosting company. We are not a design studio. We are not trying to replace the person who originally built your site. We do one specific thing, which is keep the site you already have honest about what your business actually is this week. That is on purpose, and we would rather do that one thing well than spread out into adjacent products we cannot stand behind.

The dashboard is not a feature we forgot to build. It is a thing we decided your week does not need.

See the workflow in 90 seconds.