From request queue to 765 business apps

Until recently, knowing a problem better than anyone else was not enough to build the solution. If you couldn’t code, you were stuck as a requester. AI has changed that. Not just how fast it gets built but also who gets to build it.

Our thesis: The people closest to the work know the problem best. They know where a process breaks and which details matter. When they take on building, that knowledge goes directly into the product. The solution doesn’t have to pass through someone else’s interpretation. They can shape it around the problem as they actually experience it and keep changing it until it solves the problem the way they need it solved.

veho.build is our proof. People at Veho who had never considered themselves software builders are turning firsthand knowledge into working apps. Engineering still owns the shared systems that make those apps safe and useful at company scale. But the person with the problem can now build the first version and learn from it directly.

A few days after launching veho.build, I opened the catalog of apps people had already created. lane-pricing-calculator was in there. So were veho-labor-planner, legal-invoice-tracker, and weather-disruption-dashboard. A few rows away sat meet-joke-generator and a click-streak game. The catalog looked like Veho: serious operational work next to people trying something because they could.

It contained 104 projects just eight days after launch.

I expected ownership (that’s just who we are!). I did not expect this much demand so quickly. They were not behaving like requesters who had been given a faster ticketing system. They were making apps, changing them, and asking colleagues to try them.

[Builder quote slot: A short quote from an early builder about realizing they could solve the problem themselves instead of filing a request.]

The people with the context built first

One of our dock operators built a command center for assigning forklift operators and surfacing inbound delays. They started with the details they dealt with every day, the small pieces of context that take time to get right unless you are on the ground.

A program manager built an app that ingested photos of trucks leaving dock doors and rated truck utilization. The app had a practical job. It gave operations teams something concrete to discuss when they reviewed ground-operations procedures.

An operations manager built a scanner-tracking tool for one facility and then shared it with others. Security built a guided app for API-access requests. The catalog included a facilities hub, an RFP analyzer, a coverage lookup, a transit-intelligence app, and a support decision tree.

Many of these builders start with operational knowledge rather than programming experience. They tell the AI what they need, test what it produces, and correct it using their knowledge of the work. They are not learning the problem from a ticket. They already live it. AI gives them a way to express that knowledge as software.

Anyone who has worked on internal software knows the usual relay. The person doing the work explains the problem. Someone turns it into a ticket. Product and engineering interpret the ticket. Weeks or months later, the person with the original context reviews someone else’s version of the idea.

With veho.build, the sequence changes. The person who understands the problem gets both AI and a path to deployment. They can make a first version, use it, and change it. They can show something to a teammate before asking anyone to prioritize it. The context stays with the builder. The conversation becomes, “I built a version. Can you try it?”

Scale showed up in who was building

People created about 40 apps on launch day. Most were small experiments, which was what I hoped to see. By March 6, the early production inventory listed 104 projects. When we moved them to a new production setup, 89 migrated successfully. Four were dead source, and eleven had no deployable artifact to migrate.

I like that the inventory includes the failures. A builder culture should produce experiments that go nowhere. If every idea has to justify itself before someone can try it, we have rebuilt the old queue with different tooling.

On July 15, I pulled the production catalog again. It held 778 project records. After setting aside 13 obvious test and platform records, 765 looked like business apps. Of those, 633 had been deployed at least once.

Figure 1. Point-in-time snapshots from launch day, the March production inventory, and the live production catalog.

The platform was also handling roughly 3,500 deployments a month. During one 12-day stretch in June, the automated reviewer processed 2,528 reviews of builder changes.

The activity continues after launch. People keep changing their apps. One deployment might correct a calculation. Another might add a field after someone uses the app during a morning shift. That kind of iteration rarely fits neatly into a quarterly roadmap. The person doing the work sees the need immediately.

The range grew with the count. Teams built apps for capacity planning, lane pricing, sort-cycle tracking, on-time delivery analysis, partner onboarding, and wave scheduling. Other apps supported facilities, finance, legal work, commercial conversations, and internal support. Some served one person. Others moved across a team or into another facility.

That list could make the spread feel anecdotal. The catalog showed the same pattern. Commercial and customer work had 149 apps, and network planning and transportation had 145. Ground operations and facilities had 84. People, talent, and workplace had 78, while engineering, data, and IT had 71. Apps also supported finance, internal productivity, product work, security, legal, and customer support.

Figure 2. This is a working classification of the business area each app serves. It does not identify the builder’s department.

When I grouped the same catalog by what the apps did, dashboards, analytics, and monitoring were the largest cluster, with 218 apps. I found another 117 workflows and trackers, 88 automations and assistants, and 78 calculators and planning tools. Forms, maps, portals, reference tools, and experiments filled out the catalog. Both views are based on app names and descriptions. Some apps cross boundaries, and others were too ambiguous to classify confidently, so I treat the groups as directional.

Ownership was spread widely too. The 765 likely business apps had 175 primary owners. The top 10 accounted for 149 apps, about 19 percent. The remaining 616 were spread across 165 people. Ninety-nine owners had built three apps or fewer.

Figure 3. Primary owner is the best historical proxy for who built an app because creator email exists on only 56 catalog records.

The total shows demand. Ownership shows who is acting on it. By July, 175 primary owners were maintaining apps for colleagues across operations, commercial work, finance, facilities, security, and more. That is what I mean when I say AI is changing who gets to build software.

[Builder quote slot: A quote from an app owner who did not know how to code before veho.build, describing how the app changed daily work or spread beyond the original team.]

More builders changed engineering’s job

Once AI makes a first version possible without programming experience, the bottleneck moves. The first question is how to get an idea onto a screen. Once the app works, the questions change.

Operational work repeats, so builders asked for schedules. We added scheduled tasks in March. By April, people were building with teammates, and we introduced shared workspaces. As the number of apps grew, people needed to find what already existed and see who owned it. The catalog became part of the everyday experience. Co-owners followed because people take leave, change roles, and should not be the only person responsible for an app their team depends on.

Data became central faster than I expected. Most operational work is about seeing the right information while making a decision. We built a Data MCP so builders could use company data through a managed path instead of creating a new connection for every app.

The apps also needed different kinds of access. Some were meant for a specific group inside Veho. A smaller number needed a public endpoint. We added app-level access controls, a separate public-promotion path, and automated review feedback that returned to the builder’s Cowork session.

I didn’t write this roadmap before launch. Each addition came from watching people build and seeing where they got stuck. AI now makes the first draft of an app much easier to produce. Engineering’s leverage comes from solving the shared problems around those apps once at the platform level.

Building became a shared practice

The platform changes who can build. The community changes how quickly builders learn. People began sharing prompts, examples, and debugging patterns. They asked how someone had connected a service or structured a workflow. APIs and data permissions stopped being abstract engineering topics when they stood between a team and something it wanted to build.

The weekly Builder Series gives people a place to show their work and get help. Someone can demo an app, explain where they struggled, and save the next builder from solving the same problem alone. People can contribute before learning programming syntax. They learn how to explain a problem to AI, test the result, and use their own judgment when it is wrong.

[Community quote slot: A quote from a Builder Series participant about learning from a colleague or changing their view of who can create software.]

One of Veho’s leadership principles says Vehomians are builders who can create the environment they need to be successful. That principle existed before veho.build. The platform gives people a practical way to act on it.

Agency came with responsibility

Putting software creation closer to the work also moved more responsibility to people outside traditional software teams. An app can begin as one person’s experiment and become part of a team’s daily operation before anyone decides who will support it when that person is unavailable. We saw that happen quickly. It was encouraging, and it made me uneasy.

An app people depend on raises questions about ownership, reliability, security, and cost. It may also reach a point where it belongs in a core product or engineering roadmap. Those decisions are easier to ignore while an app is still described as an experiment.

The platform carries more of that responsibility now. The catalog makes ownership visible. Shared workspaces and co-owners reduce dependence on one builder. Automated reviews catch issues before promotion. Access controls and the public-app review path reduce the chance that a useful experiment becomes an unmanaged risk.

Changing who builds doesn’t make engineering judgment less important. It changes where we apply that judgment. Engineering can build a review system or data contract once, then give every builder the same default instead of asking each app owner to solve the problem alone.

Many apps will remain team tools, and some should disappear after answering a temporary question. The ones that become important to the business will need formal support or a path into the core product. We are still getting better at recognizing those transitions.

What veho.build proves

The instinct to build was already here. The dock operator understood the gaps in forklift coordination. The operations manager knew scanner tracking could be better. The program manager could see useful information in the dock-door photos.

What held many people back was code. AI removes that barrier, and veho.build gives people a place to act on what they know. Someone can turn an observation into a working app, put it in front of colleagues, and learn from real use while the context is still fresh. Engineering still owns the difficult shared parts. The first move no longer has to be a request.

That is what the catalog represents. Its 765 business apps and 175 primary owners document a broader population of builders. The ability to create software has spread beyond people who already knew how to code.

Some of those apps won’t last, and that is healthy. Some were made to answer a temporary question. I would judge the culture change not by the utility of the apps but rather I ask myself: when people at Veho see a problem, do they feel able to try a better way?

The people closest to the problem can solve their own problems. veho.build proves that is practical.