Generate Nexus and the new age of software

The news is filled with hyperbolic claims about what AI will be capable of in the future. At Generate, we’re more interested in discussing what it can accomplish today. To understand what we’re doing and why it matters, we need to start with a question: why do companies buy software at all? 

Almost by definition, a B2B company exists to sell something for less than it would cost a buyer to build it themselves. This is obvious but the premise is important. A business buys pencils from another business because it’s cheaper than creating its own pencils. If they wanted to try, they’d need to buy the raw materials, the machines that turn the materials into pencils, and the specialized labor that can do that. But this would be immensely expensive for something as trivial as a pencil. Instead, it’s easier to buy pencils for a small price from a pencil maker.  

B2B software businesses work the same way. Modern business is run on software, but when deciding between building and buying, the economic decision almost always resolves to “buy”.  

Let’s imagine a business needs software to manage its invoicing process. This tool must hold customer info, configure invoices, perform calculations, and send out scheduled invoice emails each month. For a medium-sized business to build this from scratch, it would take a four-person team about 12 months, translating to $1M at market wages (and that doesn’t include ongoing maintenance). Hiring external engineers would be just as expensive, with a lower chance of success. 

Alternatively, you could find an invoicing Software-as-a-Service (SaaS) company, pay them $50-100K per year, and get a tool that’s just as good as the one you would have built. This is why there is a SaaS tool for every possible business process you can think of, including church bell scheduling, goat herding management, or snack room voting. For this reason, modern companies have on average 118 different SaaS tools. 

The large economic discrepancy between building and buying software ultimately comes down to engineering costs. A SaaS company spends a ton of money up front building a software tool, but amortizes those costs across their entire customer base, allowing them to charge significantly less per customer than the cost to build it. On the other hand, building custom internal software means amortizing your costs across a population of one. This is why, in all but the most extreme of cases, it makes sense to buy rather than build your IT software. 

That is, until now.  

Building Project Nexus

If the cost comparison between building and buying software ultimately comes down to engineering hours, what happens when development time drops by an order of magnitude? This is exactly what AI is doing. Agentic software development – AI agents that write, test and fix the code themselves while a person directs – is driving costs below the prices charged by typical SaaS vendors, making the build versus buy decision an actual decision rather than a fait accompli.  

Generate is embracing this change head on. This year we were faced with the scenario described above: we had to decide whether to build or buy a new invoicing tool. After some deliberation, we decided to build it ourselves, using AI at every stage of the development process. These stages can broadly be split into three parts: Requirements & Prototyping, Development, and Testing & Migration. 

Requirements & Prototyping 

The first question when building a software application (or anything for that matter) is to ask, “what are we building?” As AI cannot yet mind-read, we must figure this out ourselves. Since I was not a specialist in renewable invoicing, we needed to spend time with our invoicing team’s subject-matter expert. 

The end goal of this stage is to have a working prototype and a long requirements document. The prototype covers the “front-end” – what it looks like; and the document covers the “back-end” – how it should work. Historically, this process took months of back-and-forth, crafting your prototype and document to account for every click, number, and button in the app. 

Using AI to build the prototype and transcribe requirements calls, in three weeks we had a functional prototype and a 38,000-word requirements document. For reference, The Great Gatsby is 47,000 words.  

Development 

The next step was to pass the prototype and requirements document to an engineer on our team, who would build the application. This is where the magic of agentic development really begins to shine. Instead of months or even years, our invoicing app was built in a few days. The part of the software development process that usually takes the longest – coding – now takes the least amount of time.  

Testing & Migration 

Once the app was built, we needed to test it to make sure it was working properly. Part of this included data migration. We send out hundreds of invoices a month, so if we were going to use this tool, we had to make sure all the data had been migrated and was correct.  

By using AI to code fixes and enhancements and to do monotonous data matching, we were able to finish testing and migrations in a month, less than half the time I would have expected pre-AI.  

Putting it all together, we began this project on July 1st and completed the development in two months. With two employees allocated to this project, using market salary rates, it cost $100K to build. Actual token spend was negligible, a few thousand dollars. Altogether, that is less than a tenth of what it would have taken without AI, and one year’s worth of spend if we had purchased an off-the-shelf tool which would also come with implementation costs. But custom-built software gives you much more than just cost savings; other benefits include: 

• Simplification. Since SaaS tools need to service thousands of customers, they have more features than any one customer needs. This creates complexity and hinders adoption. With a custom solution, we can design the tool perfectly around our process. No workarounds or bloatware, just enough to do the job exactly how we want it. This greatly simplifies the knowledge required to operate our invoicing process, reducing the learning curve and key person risk. The agent and the codebase are the documentation. 

• Less specialized labor. With SaaS tools, you often need a specialist who has years of experience to make fixes and enhancements. With a custom-built solution, any IT employee with a coding agent can diagnose bugs and push changes. This makes maintenance easier rather than harder for custom solutions. 

• Unified data. With dozens of SaaS vendors, your data and business logic live in a multitude of systems, making it difficult to integrate with everything else. A custom-built solution has all our data and logic accessible, which reduces the number of integrations, and enhances the value of future builds. 

• Security. Nexus runs in our Azure tenant behind Microsoft Entra ID SSO, with permissions built around our process rather than a vendor’s role templates. Compare that with dozens of SaaS tools, each holding a copy of our data behind a login nobody has checked in months. 

• Control over the roadmap. With traditional SaaS vendors, you are at the mercy of their development timelines. Now, we can build enhancements whenever we deem it necessary.  

We decided to name our tool Nexus, which went live and sent its first invoice on October 1st. I’ve been a part of some choppy go-lives, but this wasn’t one of them. We’ve now had October and November invoices go out without a hitch, and some very satisfied stakeholders. 

Looking Forward 

Much ink has been spilled on AI causing a rapid implosion of all SaaS companies, known colloquially as the SaaSpocalypse. Predictions about how quickly this would occur were clearly overblown. As we saw with the migration to the cloud, large companies move slowly when it comes to IT. But something really has changed. Agentic development of custom software is already here – it’s just not evenly distributed. 

Another common objection to the SaaSpocalypse is that end-users aren’t going to build their own software tools. This is a valid objection, but it misses how the agentic development evolution will actually unfold. The ones spearheading the development of these custom tools are nimble IT teams acting as forward-deployed engineers, embedded alongside the stakeholders they’re serving. 

Of course, we are not yet in a world where every software tool should be developed internally. Some systems are too critical, cheap, or complex to be worth building ourselves. But we now have a very powerful lever every time we see our employees being underserved by software. 

The result of this trend is that businesses can spend more time and money on their core missions. For Generate, that’s expanding our distributed generation and energy efficiency businesses and powering data centers. A skeptic might bring up how nearly a quarter of Anthropic’s revenue comes from two customers. While this may be true, there is a long tail of ordinary, non-hyperscaler businesses getting substantial value from AI, and every one of them needs data centers and the power to run them. If building Nexus has proved anything to us, it’s that we are evidence of the long tail.