Texure

One person, about a month. I also set myself a rule: a stranger should be able to open the demo and use the thing without signing up for anything first.

The whole app runs live on sample data. Workspaces, projects with short keys like WEB-5 and OPS-1, an inbox with unread counts, notifications, quick-create, and a search box that doubles as a command palette.

My Tasks buckets work into Overdue, Today, Upcoming, and No date, with priority markers and due dates.

Workload is the more interesting screen. It puts each person's weekly capacity next to what's actually booked, eight weeks out, in hours or story points, and flags anyone who's over. Unassigned work gets its own row so it can't quietly disappear.

Dashboards are assembled from widgets. They start private to whoever made them and get shared one at a time.

Demo mode runs on seeded data and throws changes away. Point the same build at a Supabase project and it's live.

Next.js on Vercel with Supabase behind it. Demo mode serves seeded data, which is what lets the whole product open up without an account.

I built Texure partly to find out how far AI-assisted development actually goes on something real. I owned the product definition, the data model, and the interaction design. Implementation ran through AI pair-programming, and I reviewed and integrated every change.

A month, one person, a product that works. The more useful outcome was a clearer sense of where the approach pays off and where it quietly costs you time, which is the same question I deal with in AI governance work.

Live as a public demo at texure.work.

Throwing away changes is the right call for an open demo, but it means anything a visitor builds vanishes on reload. I'd add optional session-scoped persistence so someone evaluating it can set up a board, walk away, and find it still there.