FlutterFlow

YesPress · Mountain View bureau

The Builder, At 3 a.m.

It is three in the morning in São Paulo, Lagos, or Lahore. Someone has an idea, a laptop, and an unreasonable amount of coffee. They open a browser tab. They drag a button. They wire it to Firebase. By breakfast, they have a working mobile app on the App Store. They never wrote a line of Dart. FlutterFlow did the writing.

This is the part of the software industry that nobody photographed for a decade. Not the bootcamp, not the VC blogpost, not the unicorn. Just one person, alone, shipping. FlutterFlow now serves 1.3 million of them across more than 200 countries. Around 10,000 of them pay for it. A few hundred of those are Fortune 500 teams who would rather not admit how much they like it.

Polaroid: a laptop, a tab, a sticky note that reads "ship by Friday."

The Problem They Saw

Here is a riddle the software industry tells itself: writing an app should be hard, because writing an app is hard. Frameworks change. Platforms multiply. iOS deprecates something on a Tuesday and Android replies on Wednesday. Backend? You'll need a backend.

Abel Mengistu and Alex Greaves had been inside Google when they ran into this. They were on the Maps team. They moonlighted on a restaurant recommendation app. The app died - not because the idea was bad, but because the wiring was exhausting. The plumbing killed the product.

It is, in the spirit of Oscar Wilde, a perfectly modern tragedy: the better the tools became, the more of them there were to learn.

The Founders' Bet

In 2020 the two engineers left Google to make a deceptively simple bet: most of the people who want to build apps are not, strictly speaking, mobile engineers. They are designers. They are product managers. They are operators inside large companies. They are a kid in a dorm. Give them a visual canvas on top of a real production framework - Flutter - and they will surprise you.

The contrarian piece was the framework choice. Most no-code tools in 2020 spat out HTML, JavaScript, and regret. FlutterFlow chose Flutter, Google's then-new cross-platform toolkit, and bet that one codebase for iOS, Android, and the web was worth the smaller starting audience.

Y Combinator's W21 batch said yes. So did, eventually, GV - Google's own venture arm - which led a $25.5M Series A in January 2024 at a roughly $170M valuation. Gradient Ventures (Google's AI fund) and Xoogler Ventures piled in. It is the rare case of Google funding a startup that competes, gently, with parts of Google.

By the numbers, the bet looks reasonable. By the bedtime story, it looks audacious.

The Product

FlutterFlow is, on the surface, a drag-and-drop editor with a real-time preview. You assemble screens the way you would in Figma. You wire up logic with a visual action flow. You connect to Firebase or Supabase or any REST API. You hit "test on device." Your phone vibrates with the app you imagined twenty minutes earlier.

Underneath, three things are doing the heavy lifting that make engineers stop scoffing:

The Proof

Anyone can throw around a user count. FlutterFlow's interesting number is who is in that count. FairPrice Group, Singapore's largest grocery retailer, built a super-app for 13,000 employees on it. That is not a hackathon weekend. That is payroll, shifts, training, and internal comms running on a tool that was, four years ago, a side project.

The platform has shipped real apps to the App Store and Play Store for thousands of teams. The community forum has tens of thousands of members. The marketplace sells templates, custom widgets, and Dart functions to other builders, which is the kind of self-sustaining economy you used to need a decade to grow.

Hockey stick, but politely. Note the inflection right after AI shipped.

The Mission

The official line is to make it dramatically easier to build production-quality native apps. The unofficial line, the one that animates the founders in interviews, is simpler: the tools should not be the bottleneck. Ideas should be.

This is heresy, in a way. The whole modern software stack is built on the idea that complexity is a feature - a moat, a credential, a billing line item. FlutterFlow is selling the opposite. Visual where you can be visual. Code where you must. No lock-in. No priesthood.

The company runs remote-first across Mountain View, New York, and Singapore. The team is roughly 150 people. The roadmap is public. The community runs hot. None of this is incidental to the mission - it is the mission, executed in HR and Notion.

Why It Matters Tomorrow

The interesting question is not whether FlutterFlow grows. It probably will. The interesting question is what category it ends up defining. Right now the labels are slippery: low-code, no-code, visual development, AI app builder. The labels matter less than the behavior. If a designer can ship a real app in an afternoon, the org chart of software changes. The PM becomes a builder. The agency becomes a partner instead of a vendor. The internal IT backlog gets a little shorter.

The competition - Bubble, Adalo, Glide, Webflow on the web side, AI-first newcomers like v0 and Lovable - is real. The wedge FlutterFlow keeps coming back to is Flutter itself: one codebase, real native performance, clean code you can take with you. That is a deeply engineering-flavored bet inside a deeply non-engineering-flavored product. So far it has held.

Three A.M., Revisited

Go back to the laptop and the coffee. The browser tab is still open. The button still got dragged. The app still shipped before breakfast.

What changed is that nobody finds this remarkable anymore. The kid in São Paulo has a friend who did the same thing last month. The FairPrice manager has a colleague who built the internal dashboard over a weekend. The PM in Berlin stopped asking engineering for a prototype and started bringing one to the meeting.

FlutterFlow's bet was always that the people with ideas outnumber the people with patience for boilerplate. They were correct by about a factor of a million. The next factor is the one worth watching.