How CloudGo Reinforces AI Recommendations with Expert-Editable Business Context

CloudGo started as a school project at Boston University. My cofounder George and I were working on using AI to generate Terraform, the code used to set up cloud infrastructure. My professor, Leonidas Kontothanassis, helped us think about turning it into a business and later became an advisor and investor. The bigger frustration became clear as we moved from generating code to producing plans. AI could give you something that looked convincing, but an experienced person still had to work out whether it actually fit the business. A missing dependency, contractual commitment, or customer requirement could change the recommendation completely. That was the problem we kept coming back to, the expert was doing the hard work, but their corrections weren't becoming reusable knowledge. We shifted CloudGo toward making the facts and relationships behind an AI recommendation visible and editable. An expert can correct the context, rerun the work, and carry that correction forward. I eventually left my full-time job to build CloudGo, and George left his master's program.

The most useful approach has been personal outreach and introductions that lead to a conversation about someone's actual work. For our current product, that means talking with cloud service providers and consultancies about how they handle discovery, assessments, and migration planning. Those conversations helped us understand where senior engineers were spending time and which problems were important enough to pay to solve. That has opened conversations about assessments and pilots. Just as importantly, it has changed what we build and how we explain it. A specific discussion about one customer workload gives us much more useful feedback than a broad reaction to an AI platform. LinkedIn advertising was the approach that didn't make sense for us. It was too expensive and inefficient for our stage. We needed to get much clearer about the buyer and the problem before trying to scale distribution. The lesson for me has been to earn a repeatable sales conversation first. Getting in front of more people doesn't help much if they still have to figure out why the product matters to them.

The feedback that most changed our product was that a useful AI draft still leaves a lot of work for the expert reviewing it. The team needs to know whether the recommendation reflects its actual environment, requirements, and way of working. If an important detail is missing, someone has to find it, explain it, and check the next version again. Our original focus on generating infrastructure code didn't address enough of that work. Moving into planning made the gap even clearer, a technically reasonable answer could still be the wrong decision for the business. We responded by building around the knowledge guiding the output. CloudGo connects infrastructure, documents, and business requirements so an expert can inspect the relevant sources and relationships, correct them, and rerun the plan. Routine context changes shouldn't require an engineering ticket. The important part is that the correction stays available for subsequent work. That's the direction customer conversations pushed us toward, making their judgment reusable and giving them a clearer way to review the next recommendation.

People often assume the main obstacle to using AI at work is the quality of the model. Better models help, but they don't automatically know which facts, constraints, and exceptions matter inside a particular business. Take a cloud migration recommendation. Another provider might look cheaper on paper, but the company may already have a spending commitment with its current provider. A recommendation that misses that commitment can be technically sound and commercially wrong. Adding more documents doesn't guarantee that the right relationship will be understood. The people who know those details are often subject matter experts. They need a practical way to inspect and correct the knowledge guiding the recommendation without becoming software engineers. That's the opportunity we're building around. A company should be able to turn its experts' judgment into knowledge that improves future AI work. For a consultancy, the business value is less repeated discovery and review, more capacity for client work, and a better chance of preserving its methods as the team grows.

Over the next six to twelve months, I want to make CloudGo a repeatable part of how cloud service providers deliver assessments and planning work. That means making it easier for experts to review and refine context, reuse their methods, and bring the product into the next customer engagement. We're also developing API access and enterprise deployment capabilities so this knowledge can support the tools teams already use. The broader ambition is to make expertise reusable across business workflows. Our immediate test is practical, do customers pay, use CloudGo again, and get enough value to keep using it?

We've completed five cloud audits and have eleven active evaluation and scoping conversations.

My starting point was a technical school project at Boston University. George and I began with cloud infrastructure automation, working on AI-generated Terraform. Leonidas Kontothanassis, my former professor, helped us explore how that work could become a company. A lot of my practical education came from taking the product into customer conversations. I lead product, customer discovery, partnerships, and fundraising; George leads the technical architecture and delivery. Those conversations taught me how differently a useful technical capability and a business purchasing decision can look. I later left my full-time job to focus on CloudGo, and George left his master's program. We've kept changing the product as we've learned where it can do valuable work.

I underestimated how much work sits between building something technically useful and finding a problem someone will consistently pay to solve. We started with AI-generated infrastructure code and expanded into planning, but customer conversations kept exposing work that our original framing didn't address. An expert still had to reconstruct the business context, spot missing constraints, and correct the recommendation. Improving the generated output alone wasn't enough. The lesson was to pay closer attention to the work surrounding our product. That's what led us toward reusable, expert-refined context. Today, the questions I want answered are much more concrete, whose work changes, what effort goes away, and why would they use CloudGo on the next project?