Grownomic: Starting and Shutting Down an AI Startup in a Year

In January 2025, my co-founder and I started Grownomic AI with a thesis: AI could make sophisticated marketing accessible to businesses that had never been able to afford it. The techniques existed, but they were too expensive and too complex for most companies. We thought AI could change that equation. We gave ourselves a year, bootstrapped the company, and said we would find product-market fit or stop.

The Google Ads Campaign Builder

The first product was an agentic campaign builder for Google Ads. A small business owner gave us their website URL, and the system did the rest: it extracted business context, then walked the user through offer selection, keyword research, ad group structure, budget allocation, and ad copy generation. The main design decision was human-in-the-loop at every step. The AI did the heavy lifting, but the user approved each decision before moving forward.

We tested across segments including plumbing companies, junk removal services, and law firms. Law firms were the segment that stuck, and we signed paying customers there, serving them with tech we built ourselves. Those paying customers validated demand, but they also showed us how far we were from truly autonomous AI marketing, which was the actual goal. Through that work, we discovered the landing page was the bottleneck. Wiring up tracking, analytics, and CRM integration still took days even after the campaign was built. If we wanted something that could optimize itself end-to-end, the page was the piece we had to solve first.

The PPC Landing Page Builder

We talked to marketing agencies and almost all of them identified landing page work as a pain point. One told us: "If this does what you say, everyone in the industry will use it."

The first version was configuration-first. The AI configured templates, users picked layouts and set brand tokens, and the system assembled pages from components. It worked, but it felt limiting. Then the models got better. Claude Sonnet 4 and Opus 4 shipped in May 2025, and the jump in code generation quality changed our approach. By August, we had shifted the entire product to vibe coding. Instead of configuring templates, users described what they wanted in natural language and the system generated full Next.js landing pages from scratch. Each page ran on its own VM with a live preview, and users refined through a streaming chat editor. Under the hood, LangGraph orchestrated the AI planning and Aider, an open-source coding agent, executed the code edits on each VM.

We built this until the end of October. On the engineering side, it was the most technically ambitious thing I have shipped as a solo engineer, with an architecture that handled resource pooling, state machines for page lifecycle, PGMQ for async jobs, and a webhook-based deployment pipeline across dedicated VMs. But the market was moving. Generic vibe coding tools like Base44 and Lovable were already good and getting better, and we started seeing well-funded competitors building specifically in our niche of PPC landing page generation. Our specialization was not enough of a moat when general-purpose tools could do 80% of what we did and dedicated competitors were closing the remaining gap.

The ChatGPT Apps Bet

OpenAI announced ChatGPT Apps at DevDay on October 6, 2025, along with a preview of the Apps SDK built on MCP, the open standard from Anthropic for connecting AI systems to external tools. Sam Altman cited 800 million weekly active users. App submissions were not open yet, but OpenAI signalled that discovery would be part of the official release, meaning that if you configured your app metadata, tools, and descriptions correctly, your app could be surfaced to users inside conversations at the moment of intent. That was a new kind of distribution channel, and timing was critical.

Our strategy was twofold. In the short term, we would offer a ChatGPT app building and management service for companies that wanted to get on the platform but did not have the technical capability to build MCP servers themselves. We secured two pilot commitments for this. In the longer term, we planned to build a vibe coding platform that would let people create MCP servers and ChatGPT apps with no technical background, similar to what we had done with landing pages but for the ChatGPT ecosystem. The platform would include features for optimizing app metadata for discoverability and testing tools to see how users interact with your app before submission.

Alongside the service work and the platform plans, we also wanted to build our own ChatGPT app. The concept was custom merchandise: a user says "I want t-shirts for my amateur baseball league," and the app generates images, places them on selected products from a catalogue, lets the user tweak and pick, then creates an order and ships. Our hypothesis was that if we timed this right, the opportunity would be substantial because of the discoverability. Overnight, anyone on ChatGPT thinking about custom merchandise could be redirected to our app.

We were building the prototype when OpenAI opened app submissions on December 17 and published the full guidelines. The biggest blow was discovery. The feature we had built our entire thesis around was still not fully deployed and appeared to be reserved for a select set of use cases. Without discovery, the core distribution advantage we were counting on did not exist. The commerce rules added further constraints: apps could only conduct commerce for physical goods, which meant our merch app was technically allowed, but without discovery surfacing it to users at the moment of intent, the economics no longer worked. None of our apps held the same potential we had initially hoped for. As for the vibe coding platform for MCP servers, we did not have the runway or resources to invest in building a prototype given our self-imposed deadline of the end of 2025. I will write more about the full ChatGPT Apps experience in a separate post.

The Shutdown

We had given ourselves a year and we hit that mark. Another pivot would mean starting customer discovery from zero with almost no runway, and there was no indication the OpenAI policy would change. Both of us felt it was time, and we shut down Grownomic in January 2026.

Challenges and Learnings

Scoping under real constraints

We knew the classic principle: ship fast, get feedback, kill ideas early or carry on. I repeated it as a mantra, yet we somehow tricked ourselves into not following it. When we scoped work, whether a prototype or a proof of concept, we kept picking things that took too long to reach an MVP. Believe it or not, in early 2025 you actually had to type code yourself, which is ancient lore at this point, but it meant that under the constraints we had we should have scoped things much more tightly. Shipping fast also creates momentum that makes it easier to raise capital, which adds leverage, which lets you move even faster. We went back and forth between bootstrapping and raising venture money, but in either case faster customer feedback was the critical bottleneck and we were not getting it quickly enough.

Staying connected to customers

Not receiving signal for extended stretches while spending most of our time just the two of us in our own bubble took a real toll. I personally started to feel isolated and began to question what we were building and for whom, because without regular contact with actual customers it becomes hard to stay convinced that what you are doing matters. I needed to put a face on "the customer" and for too long I could not, which made it difficult to sustain the energy and conviction that a startup requires.

Deciding what to build for

Our landing page builder was a good example of a tension that came up in every major decision. The configuration-first version let us guarantee prebuilt designs that worked, but it required building an abstraction layer that might not have been necessary, and the variety was limited. When the models improved enough to vibe code entire pages from scratch, the configuration approach became a constraint rather than a feature. We were not wrong to start there, but we spent too long on it before the market shifted underneath us.

This is the broader tension between betting on the future and solving practical problems today. If you design for what is coming rather than what exists now, it is hard to get customers and hard to validate, but the reward is first mover advantage if you time it right. If you solve problems with the technology available today, you can generate revenue now, but you risk becoming obsolete in a few months. I do not think there is a clean answer to this one, and it is something I am still thinking about.

What Comes Next

For now, I started an AI consulting practice, Adaptive Gradients. I think consulting sits in an interesting sweet spot right now. On one side, you are solving actual problems for real companies, and solving them unlocks value immediately. There is no waiting for the market to catch up or for a platform to deploy a feature you are betting on. Someone has a problem, you help them fix it, and they get results.

On the other side, the work is genuinely entrepreneurial. You are finding clients, scoping engagements, managing delivery, and building a reputation. These are skills that go well beyond writing code, and I think they are the skills that will matter most in the coming years as AI changes what it means to be a technical practitioner. Consulting forces you to develop them in a way that a full-time role or a heads-down product build does not.

There is also a longer-term angle. Consulting gives you the chance to go deep into specific problem spaces across different industries and company stages. You see patterns that are hard to spot from inside a single company. The best startup ideas I have encountered came from that kind of exposure, from watching the same problem show up in enough places that you start to see the shape of a product. I am still open to starting something new if the right opportunity surfaces, and consulting is a good way to find it.