auwt

The brief

auwt started as a broad product problem: build a workspace that could handle the way real teams move between projects, client records, communications, files, analytics, and operational decisions.

That kind of app can become fragmented quickly. A CRM surface drifts away from project management. Communication history sits in another place. Files become a separate archive. AI shows up as a novelty panel instead of a useful system layer. The result is usually more navigation, more duplicated context, and more manual coordination.

The goal was to make the product feel like one operating environment, not a pile of adjacent tools.

What made it complicated

The complexity came from the number of workflows that needed to share context. A project tool can be clean when it only has to represent tasks. A CRM can be clean when it only has to represent contacts and companies. A communication surface can be clean when it only has to show messages.

auwt needed those surfaces to inform each other.

• Project activity needed to connect back to client and account context.
• Communication and files needed to support the work instead of becoming detached records.
• AI workflows needed useful context and clear boundaries.
• Admin tooling and analytics needed to make the operating state visible.

That meant the architecture had to keep the product understandable even as the feature set expanded.

The approach

I treated auwt as a platform first and a feature list second. The work centered on shared data models, reusable interface patterns, background jobs, and the connective tissue between product areas.

The stack used React, TypeScript, Node.js, Express, SQLite/Postgres, WebSockets, background processing, and third-party integrations. The important part was not the inventory of tools. It was how those tools supported a product where real-time state, long-running work, and AI-assisted decisions could coexist.

Where AI fit

The AI layer was designed as part of the workflow, not as a separate destination. That matters because a workspace product has a lot of tempting places to add a generic assistant. The useful version is narrower and more practical.

AI is strongest when it can operate against the product's real context: records, tasks, files, communication history, and the current state of work. It is weakest when it only sees a disconnected prompt.

So the product direction focused on making AI useful inside the existing operating model. That means preserving enough structure for the system to know what it is acting on, where evidence came from, and what a person should review before the work moves forward.

Why it worked

The product worked because the architecture kept returning to the same question: what does the operator need to understand next?

That question shaped the interface and the backend. It influenced how records were connected, how background work reported state, how admin tooling exposed system health, and how AI could support action without hiding important context.

It also kept the product from becoming too abstract. A workspace is only valuable if it reduces coordination cost in the actual flow of work.

The takeaway

auwt is a useful example of the kind of full-stack product work I enjoy most: broad enough to require platform thinking, concrete enough to prove whether the workflow actually helps.

The visible deliverable is an AI-enabled workspace. The more important story is the architecture underneath it: shared context, recoverable workflows, operator visibility, and enough structure for the system to keep improving without becoming fragile.