David
DeRemer

David DeRemer runs Very Good Ventures, a roughly 160-person product and venture studio that enterprises call when they want a Flutter app they can actually trust.

The work is unglamorous in the way that matters. Testing. Reliability. Architecture that survives the second year. VGV is the team that turned a Google experiment into something a CIO will stake a roadmap on, and DeRemer is the one who decided, early and against the odds, that this was the bet worth making.

His current obsession is simple to say and hard to do: better software, and a better experience for the people who build it. "If we can make better software and create a better developer experience," he says, "it will be a big win for not only developers, but also companies and end users." That is the whole thesis. Everything VGV sells flows from it.

VGV's recent moves match the talk. In 2025 the studio acquired CreateThrive, a signal that Flutter has stopped being a startup curiosity and become an enterprise default. DeRemer keeps showing up where the community gathers too, from FlutterCon stages to a January 2025 Humpday AMA with the Flutter Community on YouTube.

What separates VGV from a thousand other app shops is a refusal to treat reliability as someone else's department. DeRemer talks about testing the way other founders talk about growth. The studio open-sources tooling, publishes its standards, and builds apps the way a structural engineer builds a bridge, assuming the thing has to hold under load nobody anticipated. For enterprises weighing whether to rewrite a decade of native code, that posture is the entire sales pitch.

Hamilton wanted an app on iOS and Android. The math was brutal. "Based on their budget, timeline, and feature needs," DeRemer recalls, "we knew we could only deliver around half of what they wanted within the required time frame." Building twice, once for each platform, ate the whole budget before the interesting work began.

So VGV recommended Flutter, Google's toolkit for building from a single codebase. The catch: Flutter was pre-alpha. Untested at commercial scale. The kind of choice that gets a consultancy fired if it goes sideways.

They shipped it anyway, in roughly three months, working shoulder to shoulder with Google. The Hamilton app became the first large-scale commercial Flutter app built outside of Google, and Google returned the favor by citing it across announcements as living proof that Flutter was ready for production. One stubborn recommendation became the reference everyone else pointed to.

That pattern, spotting a tool before the market agrees it is safe, runs through DeRemer's whole resume. He has done it with food, with mobile agencies, and now with an entire framework. The Hamilton gamble worked because the alternative was worse: ship half an app, on time, or ship the whole thing on a framework that might not survive contact with production. He chose the whole thing, and the framework survived.

It is worth sitting with how unusual that call was. Consultancies are paid to be conservative. The safe recommendation is always the boring one, the proven one, the choice nobody gets fired for. DeRemer made the opposite call and then took on the work of making it true, three months of close collaboration with Google to turn a bet into a shipped, public, named product. The reward was not just a happy client. It was a reputation that would define the next chapter of the company.

Ask DeRemer for founding advice and he does not reach for vision or grit. He reaches for adaptability. "Being open to new opportunities," he says, "even if they don't fit your views or expectations, can make all the difference." Coming from someone who moved from consulting to yogurt to mobile to an entire framework, it reads less like a platitude and more like a confession of method.

The Flutter decision is the cleanest example. DeRemer did not arrive at it through a strategy deck. He arrived at it by watching. When his engineers were handed a choice between Flutter and building natively, they kept choosing Flutter, unprompted, again and again. He treated that as data. Most leaders would have demanded a business case; he trusted the people closest to the keyboard and let their preference become the company's direction.

Culture gets the same hands-off-but-deliberate treatment. There is no culture committee at VGV, no manufactured ritual. "We have always focused on nurturing our team," he says, "and that has helped us build a strong culture." It is the management philosophy of someone who believes good people, given good tools and genuine care, do not need to be choreographed.

The thread running through all of it is a conviction that the experience of building software is not separate from the quality of the software itself. Improve the developer experience, DeRemer argues, and you improve the product, the company, and the person who ends up using it. That is why VGV pours effort into testing, architecture, and open tooling that competitors might treat as overhead. To DeRemer it is the point.

It is also a worldview shaped by where he has been. A frog design strategist learns that the artifact and the experience are inseparable. A Chobani innovation manager learns that a great product still fails if the experience around it is wrong. A Penn engineer who also studied at Wharton learns to hold craft and economics in the same hand. VGV is what happens when all three lessons land on the same person.