What happens when everyone at Veho can build

Five months ago, I cancelled every meeting on my calendar for three days. I had one goal: get veho.build from idea to launch in three days without pulling the engineering team off its roadmap.

By that Thursday, it was live. And it has changed the way we run Veho.

I want to share that story today.

The idea behind veho.build was simple. The person closest to an operational problem should have a way to turn that understanding into software without having to wait. At Veho, that might mean tracking scanners in a facility, learning more from dock-door photos, or putting together a tool for a client conversation. Yes, there is a roadmap but our growth has always meant, these problems always exceed our capacity to build solutions. With veho.build, we were betting on the builder mindset of our people to solve their own problems by building apps that they need to do their job better.

The builder’s path

I started with the experience I wanted for a builder: describe the problem in plain English, answer a few questions, see a working preview, keep iterating, and ship it when it became useful.

The first version gave people a /build command in Claude Cowork. Behind it, a plugin and an MCP server let Claude take a defined set of platform actions: create a project, package an app, deploy it to staging, promote it to production, and provision storage. Every generated app started as a Next.js application with company sign-in already wired in.

I also knew people would want to connect their apps to services using API keys. I did not want someone pasting a secret into a Cowork conversation. So the platform generated a secure form on demand where the builder could enter the key and connect it to the app without putting the secret in chat.

For the builder, the machinery stayed out of the way. They could say, “I need a way to track scanners in my facility,” and begin. The platform handled the delivery work they should not have to rebuild for every internal tool.

What the three days actually looked like

Late on February 24, I committed the initial design and started on the deployment service. That service used Cloud Build, Artifact Registry, Cloud Run, and Firestore to create projects, provision databases, deploy previews, and promote apps to production.

On February 25, I connected Cowork to the platform and added the /build workflow, authentication, and the app template. I also set up infrastructure provisioning, CI/CD, and end-to-end tests. On February 26, I worked through identity, project isolation, secret handling, configuration, and the failures that surfaced only when I ran the entire system as a builder would.

DNS was one of the unfamiliar parts. I am not a DNS specialist, but I know how to ask useful questions, think through failure modes, and write tests. I used agents to work through Google Cloud DNS, and custom domains. They helped me get the unfamiliar done.

By the end of the February 24 to 27 launch window, the repository had 74 commits across 87 files. Excluding documentation and dependency lockfiles, it had about 6,300 lines of product, infrastructure, and test code.

I do not think lines of code say much about quality. I include the number to show how much ground I covered in three days. AI helped me turn a plan into a first implementation, add tests, challenge assumptions, and debug deployments. I still owned the architecture, the tradeoffs, the security model, and the decision to ship. That responsibility did not shrink. I reached the decisions faster.

I kept the first version narrow

The first launch deliberately stopped at one complete loop: describe, preview, iterate, deploy. Company sign-in was baked in. The platform provisioned infrastructure, and every app had a staging path before production. A builder could ask for a table, a form, or a scheduled summary without first learning cloud deployment.

I also drew a hard line around data access. The MVP could not call Veho platform APIs or access data-lake data. Those connections would make the apps more useful, but they would also expand the security and governance surface before we were ready. In the weeks after launch, we built a Data MCP to provide a managed path to company data. It was not part of the three-day MVP.

Databases, secrets, and project ownership belonged to the platform. I wanted builders making decisions about their problems, not inventing a new deployment and security model for every app.

Launch day

That Thursday, people created about 40 apps. Most were experiments, which was exactly what I wanted to see. People were trying their ideas, learning what the system could do, and finding its rough edges. Problems that had stalled at, “Someone should build this,” could now become something people could use and react to.

The week after launch showed us a gap

The first day also exposed a problem I was not comfortable with. The generated apps had company authentication, but each app was still directly reachable on the internet. I did not want access control to depend only on application code, and builders should not have to implement company authentication correctly in every app.

The following week, I deployed an Identity-Aware Proxy, or IAP, gateway in front of every app. That required custom URLs, a global load balancer, certificates, DNS, and a staged move away from public Cloud Run access. Once the gateway was in place, company access was checked before traffic reached an app.

Builders could keep moving quickly, but access control became a platform default instead of an app-by-app decision. The first day showed us what the platform still needed to own. We changed the architecture based on how people were actually using it.

What I took from the week

The week answered what I wanted to know. I could take veho.build from discussion to a working product in three days without diverting the engineering team. Clearing my calendar gave me the focus. AI helped me move through implementation and testing at a faster pace than I ever could have by myself.

What stayed with me was what happened next. Shipping in three days gave us evidence by Thursday and a better security model the following week. We did not have to predict every requirement in a conference room. We put the system in people’s hands, learned which safeguards had to become platform defaults, and moved them there.

Next, we will discuss how veho.build supercharged our Builder culture.