How Veho Builds

From request queue to 765 business apps

Azeem Ahmed — Mon, 20 Jul 2026 00:00:00 GMT

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.

Eight agents walk into a software factory

Azeem Ahmed — Mon, 20 Jul 2026 00:00:00 GMT

During my sprint with veho.build, I had eight coding-agent sessions running at once. For a while, it felt like a superpower. Work that would normally happen in sequence was moving in parallel.

Then I started losing track of what each session was doing.

I would open one, reconstruct the context, figure out what it needed from me, and move to the next. The agents were producing code faster than I could review it or decide what should happen next. I remember that feeling more clearly than I remember the individual tasks.

It gave me an early look at the constraint we are all going to hit. AI is making code much cheaper and faster to produce. Engineering leverage is moving to the work around the code: giving agents the right context, teaching them judgment, testing that judgment, and redesigning the workflows that connect agents and people.

veho.build gave us a place to test this with an unusual user: someone who understands an operational problem deeply but does not know how software is built. They do not know there is a pull request. They may not know what Git is. They should not have to.

If we could help that person produce software that was not perfect but sufficiently good, we would learn something about the factory engineers will need too.

The builder sees the problem, not the machinery

When a builder changes an app in Claude Cowork, a software-development process starts behind the scenes. The builder never has to manage it.

A webhook starts an agent runner. A Staff Engineer agent reads the project specification, reviews the implementation, and produces a structured list of findings. The platform passes those findings back to Claude Cowork through MCP. Cowork fixes the code, saves a new version, and sends it through review again.

Underneath that experience are branches, commits, reviews, and repeated checks. The builder sees a plain-language conversation about what is wrong, what someone using the app would experience, and what needs a decision.

That translation matters. The Staff Engineer agent does not stop at, “This API route is missing an authorization check.” It explains that one user might see another user’s information. Cowork gets the technical detail required to fix the code. The builder gets the user and business impact required to make a judgment.

The review also catches less serious problems. A layout can be confusing. A button can appear to save something when it does not. A screen can work while making the user’s job harder. The builder should be able to decide whether those problems matter now without learning the vocabulary of software review first.

This was close to what I had wanted while juggling those eight sessions: agents that could understand the work, review it, keep moving when they could, and give me a clean digest when they needed me.

A ten-minute delay can become hours

Our first instinct was to block a build whenever the Staff Engineer agent found an issue it considered blocking. It sounded responsible. It also taught us that a technically correct gate can make the larger system worse.

When a review added less than ten minutes, builders usually stayed with it. Once the delay crossed ten minutes, it often became hours. The builder started another task, missed the next review, or never returned to approve the change. The code was waiting on a person whose attention had moved somewhere else.

We changed the balance. Authentication failures and bugs that could expose data to the wrong person still stop a build. We present many other findings, including cosmetic problems and some product gaps, as advice. The builder sees the problem and its impact, then decides whether it must be fixed now.

We are still tuning the Staff Engineer agent. I do not want to pretend we have found the perfect threshold. We are trying to distinguish a safety boundary from a judgment call the builder should own, without slowing the builder enough to break their flow.

These are the knobs in the title. An agentic software factory needs more than an on or off switch for review. It needs thresholds for severity, confidence, autonomy, and interruption. Set them too loosely and the system ships problems people cannot see. Set them too tightly and people work around it or stop using it.

Context has to change with the app

The review can only be as good as the agent’s understanding of what the app is supposed to do.

As part of the Staff Engineer work, we began creating a project summary from the builder’s original conversation and the app that was implemented. That summary becomes the project specification. Later agents can read it instead of reconstructing the app from a fresh chat.

This exposed another judgment call. What should happen when the original conversation and the implementation disagree?

At first, we treated the conversation as the authority. The reviewer blocked the change, and the builder had to update the specification before continuing. That produced accurate specifications, but it also interrupted people too often as they evolved their apps.

We made the mismatch advisory. The agent still points it out. If the implementation reflects what the builder now wants, they can update the specification and the warning stops appearing. The context stays current without forcing every feature through a requirements ceremony.

I now think of the project specification as a living contract. The phrase is imperfect because contracts sound rigid, and that is exactly what we learned to avoid. The specification should guide the next agent and record what the builder has decided. It should also be easy to correct.

We have seen what happens when context arrives too late. Some builders started apps independently in Claude and then tried to bring them into veho.build. One had accumulated so many assumptions that Cowork did not use the veho.build template at all. I tried to preserve what the builder had while satisfying the platform’s requirements. We ended up with a hodgepodge that is now being rewritten. A few times, we have asked builders to restart inside veho.build because retrofitting would take longer and produce a worse result.

The labor-planning app is the counterexample. It is at least as complex, but the builder started inside veho.build and worked methodically. He built a small piece, used it, then added another feature. He did not begin with a broad prompt and spend the next several rounds removing what he did not need. A clear problem definition probably helped him more than anything else. Each iteration gave the next one better context, and the result so far has been strong.

The software factory cannot be added at the end. It has to shape the work from the first conversation.

Engineers have to teach agents judgment

A generic code reviewer can find generic problems. That will not be enough for the next software factory.

Our Staff Engineer agent carries Veho-specific context. It knows how authentication works in veho.build apps. It reads the app’s product intent, not only the changed code. It looks for cases where a screen presents sample data as live, where a save button does not persist anything, or where the implementation runs but does not deliver what the builder asked for.

For apps that may become accessible outside Veho, we add a separate Legal review. We worked with our Legal team to express its policy as ladders of risk an agent can apply. The agent can inspect what an app collects, whether it has the right notices and consent, how long it retains information, and whether public access requires a different review.

We are also building a risk agent that will advise Claude Cowork while an app is being built. We want to prevent avoidable risk earlier, instead of only reporting it at the end. We have not solved this yet. Legal has produced a policy the agent can process. Now we need evals that show whether it applies that policy correctly.

The evals should resemble the mistakes we care about. Does the agent catch an authentication bypass? Does it recognize that a safety-intake form should not follow the normal path for a public app? Can it tell a static public page from a form that collects personal information? Does it flag a fake privacy link or a retention promise the code does not honor?

When an agent gets one of those cases wrong, correcting that answer is not enough. The miss should become a test. Then we improve the policy, the agent’s instructions, or the context it receives and run the eval again. The pieces improve in a loop.

That is high-leverage engineering work. Engineers will still write code, but more of their impact will come from creating conditions in which agents make good decisions repeatedly.

We are building an agent platform to make this repeatable, and I will share more about it soon. The lesson from veho.build is simpler: a capable agent is only part of the system. Its output depends on the context around it, the judgment people teach it, the tests that challenge it, and the decisions people keep for themselves.

Code volume changes the bottleneck

We already have a glimpse of what happens when technical users work this way. One Veho engineer, working as a single engineer, has shipped more than 1,000 pull requests with meaningful code contributions to production in less than six months.

That changes the engineering problem. When one person can produce that much deployed work, code generation is no longer the scarce resource. Review is the first bottleneck we have to get right.

Context and memory are close behind. Agents fail when they reason from the wrong history, carry an outdated assumption forward, or misunderstand how one part of the system constrains another. Faster code generation makes those errors arrive faster too.

Most engineering workflows were designed for changes produced at human speed. A pull request enters a queue. Someone reviews it. Tests run. The change merges and deploys. Feedback comes later. Automating individual steps will help, but it will not be enough when the number of changes multiplies.

We will have to redesign review, testing, CI, merging, deployment, and feedback around agent speed. Agents should keep moving inside known boundaries. They should stop when they reach a decision about architecture, product scope, data access, security, or a constraint that materially hurts the user. When they stop, they should produce a digest with the tradeoffs and approvals required, not hand a person five chat transcripts and ask them to reconstruct the situation.

That is the system I wanted when I had eight sessions open. I wanted agents to continue until they reached a boundary they should not cross, then bring me the decisions in a form I could process. I would still review and approve the important parts. I would no longer have to route every intermediate step myself. That will then allow us to test where that boundary should be.

What veho.build taught me about the factory

veho.build began as a way for people closest to an operational problem to build the tool they needed. It has also become a practical experiment in how software gets made when AI writes much of the code.

Let’s look at the labor-planner built by one of our Builders. The builder had a clear problem and worked incrementally. The Staff Engineer agent had product and platform context. Legal turned its policy into risk levels an agent could apply. Evals give us a way to test whether the agent applies that judgment. The review loop keeps the engineering machinery out of the builder’s way while returning important decisions in plain language.

None of this is perfect. We are still tuning which findings should block, how quickly reviews return, how the specification changes, and how far agents should go before asking for approval. I expect that work to continue because the balance changes as the agents improve and people trust them with more consequential work.

AI is making code abundant. The advantage will come from the context, judgment, evals, and workflows that help agents produce the right software without losing the human along the way.

This is the final article in the veho.build series. The next question is larger than veho.build. If agents can plan, build, review, test, and deploy at this speed, what should software engineering become? What roles should product and design play?

That is the journey we are on in our engineering and data science teams. The craft of engineering and data science is evolving and snapping to different boundaries. The roles we are used to working with in delivering software are being redefined around us. It is our job to help shape that frontier. More on this in a future series…

What happens when everyone at Veho can build

Azeem Ahmed — Mon, 20 Jul 2026 00:00:00 GMT

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.

Veho is a super weird software company

David Jackson — Mon, 20 Jul 2026 00:00:00 GMT

(This post is not about AI)

If I’m going to make this claim I feel the need to establish my credibility in evaluating corporate and workplace deviance. If you’re feeling credulous, you can skip this curious credentialing cruft and jump right into the bits about Veho.

When people ask what I do, I typically pantomime typing, mumble something about software and say it is not interesting. If they ask a followup question, I say that people pay me to make computers do things for them. This evasiveness is a gift! I am giving them a chance to get out psychically unharmed. I am a deeply boring and prolix communicator, and the nature of my day to day software work leads me to have very strong opinions about things like the best UUID format (type prefixed UUID7) and the ideal operating force for keyboard switches (55cN).

Those who choose to persist in the conversation find that my career trajectory at various startups has been more “fruit fly flight path” than “up and to the right.” I have worked on federal fraud litigation, live UFC fight statistics, high-traffic mobile app infrastructure, materials science AI platforms and feature definition formats, and now e-commerce logistics. I’ve worked nights in an ice-cold broadcast trailer behind the MGM Grand fixing bugs in the punch-and-kick-counting algorithm in an Adobe Flash app. I’ve physically deprecated python code in a paper shredder to ensure the correct version was provided during discovery. I’ve spent hours with charming nerds from NIST debating whether humidity is a “measured parameter” or a “calculated condition” of an industrial process (we settled on: “it depends”). I was once remoted into one of those ipad-on-a-segway telepresence robots and suddenly warned that I needed to stop threatening people. Someone (not me, I was 3,000 miles away) had taped an open pocketknife to the iPad the day before and I had been unwittingly stabbing office plants on my way to a conference room. And yet, Veho is the weirdest company I’ve worked for and it’s not particularly close.

Econ 101: Veho shouldn’t exist

The first weird thing about being a software engineer at Veho is that the company exists. Industries with huge fixed costs and outsize returns to scale are what economists refer to as natural monopolies. Logistics networks tick nearly every box. To run a shipping company at scale, you need: huge amounts of warehouse space broadly distributed across a large geographic area, thousands of drivers, and hundreds of trucks running 24/7. You also need enough clients shipping packages to fill daily truck lanes running long haul from LA to Atlanta but also short ones from Philadelphia to Newark — if you can’t fill the trucks then you either deliver late or lose money running them half-full. Adding last mile delivery makes the math even worse. The unit economics work great if you have so many packages that you are dropping 20 on each block, but if there are 3 miles between stops you’re just burning cash.

Veho is a startup that runs a coast-to-coast logistics network across 33 states while offering last mile delivery to a majority of people in the US. We deliver to people’s doorsteps faster and more reliably than companies two or three orders of magnitude larger, and we compete with them on price. Just structurally, it shouldn’t be possible for this company to exist. The returns to scale from running huge, busy networks consisting of bought-and-paid-for real estate should allow our competitors to trivially undercut us on price, speed, and reliability. This shouldn’t be working, but every year I’ve been here we’ve grown margins, the network, and the number of packages we ship.

Working here doesn’t suck as much as it should

The second weird thing about being a software engineer at Veho is that the job doesn’t totally suck. There’s a sort of an unwritten rule that if you are a software engineer working in a cost center — if the company doesn’t sell a digital product you make — your job will suck. You’ll have impossible amounts of work, be compensated terribly, and leadership’s general opinion of what you do will oscillate from delusional optimism to frustrated confusion to disappointment and layoffs. Your best case scenario is that some powerpoint wielding hero convinces a “real” VP to accept the necessary evil of giving you a COLA after some software you write saves the company 10x your total compensation. I don’t make the rules! I just work here.

I think the main reason Veho operates this way is empathy? The people who work here have a lot in common with the folks whose stuff we are delivering. We shop online! We do not like it when our stuff arrives late. We know that a late truck carrying a meal kit can mean that a family’s dinner isn’t on the table. As a result, folks are shockingly grateful for new internal apps that improve outcomes on the road. My theory is that when the impact of merging a PR can be seen in metrics and SLAs but also felt in the orbitofrontal cortex of other Veho employees, we work together more closely and it sucks less.

It’s also possible that since the rules say that the company shouldn’t exist in the first place, Fred and Ita just channelled Meek and YT and threw out the “abuse the devs” rule, too. Either way, there is a connection between this and the next point:

We write and ship a ton of software

The third weird thing about being a software engineer here is that Veho doesn’t sell any digital products. We get paid to move millions of boxes and polybags. We deliver them by running a huge physical distributed system that sorts, ships, and delivers packages to people’s doors. Growing, monitoring, debugging, and optimizing that physical distributed system is the whole job — it’s what everyone in the company is doing, every day. A system of this size forces our hand. We are too big to try to do anything manually, and too small to afford the cash-wasting inefficiencies of buying and integrating siloed, not-quite-right off the shelf software from existing logistics vendors.

So at Veho, the default approach to solving problems is writing and shipping software ourselves. We have no shortage of problems, so we ship a ton of software. As of this writing we have 770 Github repositories. Non-engineers have shipped hundreds more vibe-coded apps since we built our own internal no-code app platform. We run three completely different mobile apps, our own driver marketplace, and dozens of internal and external APIs and database systems. We integrate with Twilio to notify folks when their packages will arrive. We collect proprietary data on the “last 100 feet” to ensure packages land on time, exactly where people want them. We have a custom warehouse management system tracking the status of every package, pallet, and dock door throughout the network. We’ve got dozens of different ML systems in production doing everything from creating new, optimized delivery routes every day to pinging freight brokers in slack asking for late-arriving truck ETAs. We have hundreds of data mart tables providing everyone in the company access to every piece of data we can think of to measure or monitor.

This is not normal behavior! It is not normal for people to obsess over how to shave seconds off the amount of time it takes to deliver a package by reducing latency and crash rate on seven-year-old underpowered Android phones. It is not normal to spend hours revising metrics to identify the impact of a reduced crash rate and ensure the resulting benefit persists over time. We aren’t selling this software to anyone! Nobody outside the company will ever even know we did all this!

Unless… should we start an eng blog?