Build Log #03: Google says its tools can run your whole organization. I tested that.

The short version: I took Google’s claim that its Workspace tools can run a whole organization as a dare to myself, and built a working improvement app out of nothing but Google products. The moment I tried to break it is the best part.

Earlier this month I asked a colleague to lend me a problem. I’ve spent this year building an assembly line of AI tools that can take an idea and turn it into working software. I call it PRISM: a set of AI skills that runs like a conveyor belt, where one stage researches the idea and proves it with a working mockup, the next writes down the rules, another designs the screens, another writes the code, and the last one tests what got built. I’m not a coder. I’m a bit technical, but not at the level of a developer, and PRISM is how I build real software anyway.

I wanted to point it at something I didn’t control, something from another person’s real work. My colleague had a project they had been nursing along for a while, and they took me up on the offer to see what I could do with it. I went in expecting to be impressed by my own system.

I wasn’t, and it took me a minute to understand why, because the tools had done exactly what I asked. The material they were handed was the problem. The project was a pile of reference documents, useful to read and impossible to run. Nothing in it had ever been designed around how a person actually works through a problem, where feedback goes once somebody gives it, or how a piece of work moves from “someone should look at this” to “this is handled.” My system dressed it all up and organized it, and what came out was still a filing cabinet pretending to be a process. Arriving in the middle of something that was never built as a system, the best any tool could do was polish what was already there.

I wrote about that rescue attempt in the last issue. This is the part that came after.

The disappointment bothered me more than it probably should have, and for a specific reason. I spent over 10 years managing reporting and business systems for a national nonprofit, so I know what a working improvement process needs, because I lived inside one. Problems need a way in and an owner once they arrive. Goals need numbers attached, and there has to be a loop that tells you honestly whether things are getting better or just getting talked about. I could see everything the rescue attempt was missing. What I didn’t know was whether I, or should I say PRISM, could build the real thing, since I don’t write code. Sitting with that gap, between seeing the answer clearly and not knowing whether my build system could actually make it, was the low point of my month.

Around then I remembered a claim Google makes in its Workspace marketing, the quiet one: that these tools are everything an organization needs to run. I had always read that as a sales line. This time it landed differently, and I took it as a dare to myself. If the claim is true, it should be possible to build an actual improvement application out of nothing but Google products. Real sign-ins with real permissions, goals with targets, the full loop, and none of it running on anything beyond what an organization already pays Google for. I stopped trying to fix my colleague’s project and started testing Google’s claim instead.

I ran it in stages, the way I’d run any test where I expected to be wrong at least once. The first stage was pure research, a feasibility study to find out where the hard limits were. That research ran through the front of the conveyor belt, the stage I call prism-think, whose whole job is to find the walls before I spend days building toward one.

Before building anything I would call real, I built a proof of concept. A proof of concept is a rough version whose only job is to show that the risky parts can work at all, and here the risky parts were the ones Google’s marketing glosses over: real sign-ins with real permissions, and hard walls between what different users are allowed to see. The only way to prove that was to become my own customer. I used my own domain, made myself the administrator, and created 2 test users, a regional manager and a site manager. Then PRISM handed me a test script, and I worked through every step by hand.

The test I had been putting off was trying to break it. I’ll admit I expected to catch my own app lying to me. I signed into the same record from 2 of those accounts at once and had both try to save. The first save went through and became the record’s seventh saved version. The second account was stopped cold with a message telling it the request had changed and to reload before saving. Nothing got lost or doubled, and I sat there for a second enjoying that error message, because it is the difference between software and a shared document everyone quietly overwrites. Then I went at the walls. I signed in as the regional manager and hunted for other regions, signed in as the site manager and hunted for other sites, and found that each account saw exactly its own slice of the organization and not one row more. The proof of concept held, and that is the moment this stopped being an argument with a marketing page and became an application.

The real build started with the smallest slice I would trust, which was intake. My operations years taught me that every process lives or dies at the point where information enters, so the first piece was one screen where a problem gets recorded, somebody gets named as responsible, and the next step is written down. From there the app grew 4 kinds of users. An administrator who sees everything, regional staff who see their region and nothing else, site staff who see their one site, and viewers who can look but not touch. Same link for everyone; the app decides what you are allowed to see after you sign in.

Each new layer got tested the way the proof of concept did, and some of that verification I had to do with my own hands, because Google runs these apps inside a sealed window that automated testing tools can click but cannot actually see into. So I worked the mouse while the AI read each screen and checked the arithmetic, and that arrangement caught 2 bugs that every automated test had sailed past. Those 2 bugs are the part that keeps me honest. The tests said everything passed. It took a person, looking, to find what they missed.

One piece came from my own history. An earlier app I built had a playbook idea in it, guidance that changes depending on where a goal stands, and I folded that thinking into this build: when a goal drifts off track, the app should have something useful to say about what to do next, drawn from a playbook the team controls. The idea is that a goal that is on track gets left alone, a goal that is drifting gets the playbook opened to the right page, and every action the team takes gets tracked so they can see whether it actually moved the number. Intake is built. The measuring layer behind it is built and has survived real accounts trying to break it. The guidance layer is the last big piece. It is built now, and you can click it in the demo, but I have not run it against a live organization yet. That part gets its own issue when I have.

What still surprises me is how it looks. The screen looks like software a company would charge real money for, and behind that screen there is no server and no real database. The backend is a spreadsheet and some documents, dressed in an interface that hides all of it. The app doesn’t even have a real name yet. I’ve been calling it Plumb, as in plumbing, because the point of the whole thing is flow: work entering a pipe, moving through it, and coming out the other end finished. Silly, I know, but I have no plans yet for turning it into a real product, so I didn’t want to spend the mental energy on a name. But the answer to my question is yes, mostly. Google’s tools can run a real improvement process, if someone who understands how work should flow is willing to make them prove it.

You can click through it yourself. I could not put the real one on the internet, because it runs on my own Google account and can reach my files and send mail as me, so opening it to the public would hand strangers a door into my own workspace. What is at the link below is the same interface running on invented data inside your browser, with nothing to sign in to. Switch the role at the top and watch the app shrink: an administrator sees every site, regional staff see one region, site staff see one. Create a request and move it along, and the version number climbs and the history fills in the way it does in the real thing.

Open the demo: https://rodneybuilds.com/plumb-demo

What claim does a tool you already pay for keep making that you have never tested? Hit reply and tell me. I read every reply.