How Sandgarden Came to Be

In my last post, I promised to spend more time explaining how Sandgarden came to be.  Today is your lucky day! 

‍

We were four friends, brainstorming for what felt like a year.  It actually was a year.  Maybe three months in, Britt said, “I want WPEngine for LLMs”.  We were all like “nah, it’s already done, there’s no way this could actually be a need blah blah blah” and “there are cooler ideas than that, it’s so boring”, the latter of which he agreed with.  Nine months later, he was still reaching for the same thing, and even close friends whose full-time job is being a VC started wondering if there was something there.  For us brainstormers, we knew the development need was there even if we didn’t know where the market was.

‍

So we started Sandgarden.  For most startups, the bet is the people.  Can they do this?  Can they build?  For me, I’d argue the bet for any AI or AI-adjacent startup is market timing.  If it’s hit right, the company is golden.  And if not, it’s way off.  An investor told me about a synthetic data startup that came into existence 5 years ago that ended up getting acquihired.  Launch it now, and they’d be CRUSHING IT.  

‍

What’s the first thing a good founder does?  Poll their network.  The quotes we got back from a wide range of titles were eye-opening:

‍

• “The space is so new that we don't even know what's going to go wrong yet.”
• “I don't have confidence today that we're going to train a model and that it's going to produce anything useful. And that we'll end up spending tons of time tweaking/iterating/training before we get anything useful. I wish I could reduce that time risk and increase my confidence that we'd reach good output.”
• “I don't want my team to have to become experts in all the specific sub-components, that would be perfect. Just have a platform that runs against 4 different versions and show me what works best.”
• “The product team is [probably] the main driver, and having something that they can just quickly spin up as non technical and experiment with is key.”
• “AIs are a lot of work to squeeze, but appear to produce little juice”
• “I need to make it easier for my team to experiment.”

‍

It validated that the technology was interesting, that folks weren’t sure how to approach nor perceive it, and that there was certainly a steep learning curve.  I’d maybe extend that argument a step further and say that AI is like no development previously, or perhaps being less provocative than that, it certainly turns the current precedent of “product outlines, engineers build” on its head.  If PMs require engineers to spec out whether or not something is worth building, then PMs are effectively neutered.  Engineers become tasked with something that 1) isn’t their area of expertise, 2) that distracts them from other things, and 3) effectively adds a cost center to a business, because if they’re focusing on something else without guaranteed payoff, and they’re not working on coding which does have a guaranteed payoff (i.e. it's been approved by management, which means there’s a reason), then they’re sinking payroll into a gamble and risking future revenue.

‍

We don’t think that should be the case.  Sandgarden aims to normalize development with AI into today’s standard: PMs spec, engineers build, infrastructure has confidence in what’s being deployed, folks are able to align to today’s rapid prototyping standard and not a “once a year deployment” a la hardware, and everyone gets to do it in a single platform.  That’s Sandgarden.  One place to do everything you need with AI integration, for all teams.  And do it well.  Try us today :)