If you think about it, LLM providers are distributed systems on steroids. Building reliable systems with them, comes with particular challenges. A modern day developer should have proper skills of using LLMs in systems at scale.

Some of the problems one may face when building AI agents using model providers could be:

• Unreliable output of the LLM providers specially with regards to the requested format in the prompt.
• Running into rate limits boundaries of the provider.
• Model quality of output dropping or an outage on the provider side.
• Huge cost of tokens when using llms at scale.

My goal in this blog post is to give the builder a mind frame on how to build cool stuff with these systems in a reliable and scalable fashion.

Reliability​

When it comes to reliability, there are a few needs that a developer has to address right off the bat. First and foremost, is LLM providers’ rate limit boundaries. For this purpose, I used technologies such as LLM gateways where one needs to keep track of the token usage by a model and switch providers if the limits are within reach. I’ve used [Portkey] (https://portkey.ai/) in the past for this purpose. It’s open source and easy to use, you just need to pass in a config file and you are good to go.

The second important reliability issue, is the format of the output returned by the provider. Imagine your prompt asked for an LLM to return its output in json format, but on the 6th try, a string output is received. Fortunately for us, the providers have a field called response_type where one can pass the type of expected response in the header of the request. The format of this header varies based on specific providers. Please refer the documentation of the provider used for the specific format.

For providers unexpected outage purposes, there two solutions I’ve used in the past. The first solution is using default fallback cases with try catch phrases (i.e default object definitions), so your objects don’t become null suddenly and ur system doesn’t crash.

The second is having another provider as a backup in case one fails in your logic.

Saving Cost​

The fastest way to have cost saving, is enabling caching mechanism before the user input reaches the provider. If you have a cache hit, boom, you don’t need to pay the provider. This is particularly good when you are testing with the same data multiple times during development. That way you don’t have to pay for tokens while testing. Portkey also provides simple caching system on top of your LLM calls.

You can go nuts here and use a vector database as well. It’s a pretty cool system for building memory for agents and create a converging “history” systems. In the past I’ve used Pinecone for vector database purposes, however there are many other opensource alternatives that I would like to play around with as well. Trychroma is a notable one. If you haven’t worked with vector databases before, they are basically databases that store flat data in vector formats, so you can capture higher dimensional relationships between them. If you are interested read this document for deeper understanding of vector dbs: what is a vector database.

Another cost saving mechanism is fixing the output’s token count with a header variable you pass to the provider. Again each llm provider have their own variable for this and you would have to refer to their documentation. Only risk for token output fixing is getting a truncated output. Be aware of this and handle it with grace if you decide to implement token truncating.

Reaching for Better Quality​

We all know how ai can be slopish and at times very spikey. That’s why I write all these blogs by my hand with zero ai involved 😁. Personally I have used multiple layers for this purpose and put a supervisor llm at the end where it determines the quality of the previous layers’ output. You can also use more deterministic systems such as large data sets formed into a vector format and check the llm’s output at different stages against it to verify some sort of quality of response.

Final Thought​

I hope this article came helpful for developers to build a mind frame around building with these systems. Its really fun to play around with these systems as a developer. If you like to work with me, shoot me an email, or join our Discord Community of builders and build amazing things together. It’s an amazing time to be a builder and hope you all are as excited as I am.

When I first started building integrations to a huge system, I thought it would be a piece of cake. As with building systems in general, I realized they are not necessarily as easy as I thought they would be. There are issues that reveal themselves to you once you are deep into the process. Issues such as:

• Which system has the latest version of data? What is your tell?
• How do you synchronize data between the two systems to preserve the latest most correct data.
• How do you manage the data so every time you synchronize both systems, you don’t have to rewrite all the data. What are the boundaries of the system you are integrating to? What do they allow you to do and what do they not?

As with building systems go, once you work at a problem long enough, the answers reveal themselves to you. So I will be sharing some of my approaches to these problems. My goal is to set a mind frame on how to approach huge integrations from the beginning.

Before Begining the Integration​

When you start integrating into another major provider, I recommend spending some time in their documentation, understanding their apis and database design decisions. I understand AI is great at coding these days, and you can push stuff pretty far with it, but you are still the driver. It will save you time if you drive the machine right. Focus on understanding the boundaries of the external systems as well. What are some of the things that they don’t allow you to do. This is specifically important to understand early on. It holds you back from chasing dead ends and solving impossible problems.

Studying big players APIs is a great place to start when approaching to design a software in a specific vertical. For example, if you want to build an accounting software, I recommend digging deep into Xero platform’s api. This will show you abstractions that you might be missing in the beginning, in your DB design. It will also give you a very mature view of a system ahead of time.

What an integration is consistent of​

An integration is formed from three major things. A sync, a resync and export. Syncing takes the data from the external system to your system. Resync is how your system matches its data with the external system after the initial Sync. Finally, export is how your system sends data from your system to the external system. I recommend implementing in three separate stages (move vertically). Finishing Sync completely, enables you to make all your mistakes and not having to fix it in three different places. I say this because I tried doing sync, resync and export at the same time for each object (moving horizontally). This caused a lot of pain, because if a mistake was made about the third party’s object I had to go back and fix it in three different places.

Part 1: Sync​

I recommend starting with Sync, it allows you to deeply understand the third parties system and be prepared for next stages of the integration. Store the external objects id in the database, so you can find it later on, this is important. Recording time when a synchronization happens between two systems is important. At the end of the day, time can be your tell for what is the latest version of the data. Try to not complicate things, if something has already been exported to the third party, don’t allow the user to edit that field again on your platform, this avoids complications of finding who is the source of truth, and constantly syncing stuff.

Part 2: Export​

Then move to Export. Make sure you have a tell in your database of what object has already been exported to the third party platform. Another important factor about export is making sure you are not writing old data to the third party platform. This is where last sync time comes in handy. Also keep your updated_at field up to date when users change an object on your system, this will save you a lot of headaches later on.

Part 3: Resync​

Resync is a very important piece. Even tho when you get to resync you are tired from implementing the Sync and Export logic, don’t take it lightly. A method I chose for resync was called modified since. The third party applications usually accept a time variable in their header. It will return objects that have been modified after that specific time. In that way you can make sure the data you have on your application are synced with the latest data on the third party platform. Finally, make sure you cover all the CRUD cases, specially deleted objects on the third party. Sometimes the modified since doesn’t cover deleted objects on the third party causing you to face some weird problems when you are in production.

I recommend wrapping your Resync function in a cron job. The resync cron job that runs for example every day, makes sure your system and the third party system don’t diverge from each other too far. Its also not a bad idea to run your resync function before each export, just to make sure your data is not out dated between the last resync and export times.

Final Thought​

Integrations are a challenging problem, and are unique to each system. There will be weird stuff that will come up as you build the integration. My aim in this blog post was just to give you an overview and a thinking mind frame when approaching this problem. Maybe you can feed this blog post to your coding agent when you are starting to code a big integration. We are agent friendly, we don’t block coding agents from accessing our website.

I've been building an app for a client I can't mention the app yet because she hasn't released it yet, but essentially it's linktr.ee for people who host events. It's fairly common app so I figured it'd be cool to share my tech stack and a short blurb on why I chose the tool.

Here's my full tech stack breakdown:

• Framework (NextJS) - The opinionated framework makes development a breeze. I'm able to actually focus on the app rather than setting up the code.
• State Manager (Plain React / Supabase) - Honestly with NextJS server routing, I'm able to pass required states from the server and get away with simple plain react states. It's a lot simpler and removes the headache of having another state manager.
• Language (Typescript) - Typescript is TOOO good. Having to not worry about the mysterious types saves sooo much time. One thing to note is that, I use types directly generated from Supabase. Highly recommend doing this!
• Components (ShadCN/UI) - This one speeds up the front-end work massively. It allows me to only focus on the placement rather than designing the component. One note here, is that I'd recommend copying the placement of similar functioning websites (e.g. copy Apple Notes UI for your note-taking app). They've probably spent hundreds of man hours optimizing for UI so leverage that.
• Styling (TailwindCSS) - This is a no brainer. Tailwind makes adjusting the styling a breeze and allows for me to quickly make changes without having to
• Database (Supabase) - Supabase is a PostgreSQL wrapper that makes it super easy to setup. It is also scales nicely. Highly HIGHLY recommend!
• Auth (Supabase Auth) - The integration between the database and auth is seamless and the client libraries make it a breeze to work with. I recommend checkout out their auth guide to see how to set it up with NextJS.
• Server (Supabase Edge Functions) - Most of the time I don't need server processing because I can directly go through Supabase with it's client library. But when I do (e.g. making calls to OpenAI), I use Supabase Edge Functions. It's bundled with the pricing and the client library makes it easy to call.
• Storage (Supabase Storage) - The client library, Supabase integration, and pricing make it a no brainer for me to use Supabase storage since I'm using it for pretty much everything already.
• Hosting (Vercel) - Hosting on Vercel with Supabase is a breeze. It also has a generous free plan like Supabase
• Icons (React Icons) - React Icons is comprehensive and is easy to work with. If you don't need that many icons I recommend only using Lucide Icons, which is already bundled with ShadCN/UI
• Analytics (Posthog) - It's important to have analytics, posthog makes it such a breeze and integrates well with other platforms (e.g. Stripe) to have a full view of your business.
• Email (Postmark) - Postmark has been working well as an email marketing platform but to be honest, I've been looking at a more comprehensive email platform that also makes it easy to setup complicated email campaigns. Might migrate to loops.so.
• Payments (Stripe) - Stripe is an amazing platform and is pretty much the goto payments platform for most SaaS companies. It integrates with pretty much everything and is easy to use.
• Payments Sync (Supabase Edge Functions) - One caveat of using Stripe is that it's often difficult to keep track of payments within your app. What I've done is I setup a sync between Stripe and Supabase through Supabase Edge Functions. You can see my code here.

P.S. i've also created a template of above in Github. Feel free to check it out here

This is my guide on the fastest way to get paid with Stripe and Flutter. I'll walk through step-by-step instructions on how I set up stripe integration, how I associate purchases (subscriptions & one-time payments) with users, and how I keep track of all of that within Supabase. Afterwards, I'll talk about the review process and how to tip-toe around the strict AppStore rules.

Stripe + Supabase Integration​

Stripe has a lot of built-in complexity to handle many edge cases. But at the end of the day, what's most important on the Supabase side is to know which user purchased what product or whether or not they are subscribed. My approach to this is to have an active_products column that is synced with Stripe and keeps track of the users' purchased products and products they are currently subscribed to. I also take advantage of Stripe's checkout portal so I don't need to create the payment UI myself.

User Payment Flow​

1. User creates an account (through Supabase)
2. The user goes to the pricing page and selects a payment option
3. The link redirects them to the Flutter app with the price id from Stripe
4. A function is called from the Flutter app which creates a custom checkout portal link
5. The user is redirected to the stripe portal link and makes the purchase
6. A stripe webhook is triggered which updates active_products
7. After the purchase, the user is redirected back to the app
8. The app now knows the user's purchases through the stripe table

Setup​

1. To get things started, you'll need to set up a Stripe account and a Supabase account.
2. Run the following SQL commands to create Stripe tables that will sync with stripe
3. Create two Supabase functions, one to generate a checkout link and another to handle stripe webhooks.
4. After deploying the functions, connect the webhook with Stripe and select all events.
5. Enable, the checkout portal in stripe by clicking "Save Changes".
6. Now in your Flutter app, you can call the checkout function to generate a link so the user can begin their checkout
7. Finally, you can make a simple query to check whether or not the user is subscribed

If you're also interested in setting up analytics, transactional emails, release pipelines, or just want to play around with the demo, I encourage you to check out my open-source flutter production boilerplate. It has everything you need to build your startup.

Tip Toeing the Android and Apple App Store​

So now you have Stripe set up with the checkout portal and webhooks in place, the payment process should work for web apps. But, the Apple App Store and Google Play Stores have strict guidelines on what can and cannot be done. There are ways to tiptoe around these guidelines. For example, apps like Netflix, Spotify, and Audible use this approach to circumvent the huge 30% commission Apple has. For us, we do it because it's a hassle to integrate with the respective app stores.

Here's how these companies do it:

• Netflix: You are only able to sign in from the app, you are unable to sign up and pay.
• Spotify: When you try to access a premium feature, it directs you to a page that says "You can't upgrade to Premium in the app. We know, it's not ideal."
• Audible: When you click "Buy more Credits" you see a current subscription page with text saying "To manage your account, visit the Audible site or call customer support"

Depending on what type of app you have and what business model you are using you can try one of the approaches above. Below are additional tips to help get you approved:

• Do not mention payments within the app and remove all links to the pricing page. I use the kIsWeb flag (or Platform flags) to hide payment stuff in Flutter.
• Remove your paywalls, and direct the user to a page to tell them to manage their account on the web. Use wording similar to Spotify or Audible.

Additional Options:​

Depending on your app sometimes, it doesn't make sense to tip-toe around the app store. Below is a pros and cons table to help you figure out which solution is the best for you. I either recommend using Stripe or RevenueCat, it doesn't make sense to do a self-implementation of this.

Note: You can sign up for Apple's small business program to only get charged 15% commission fee instead of 30%

TLDR; Worked as a CTO of a YC-backed company but broke up with my co-founder due to a difference in values. Now I'm helping developers build their startups.

Pre-breakup​

A couple of months ago, my co-founder and I were working on an AI education startup. We were YC-backed, grew to 50,000 users, and earned $10,000 in revenue in under three months. All these metrics seemed to point towards a product with product-market fit, yet we were far from achieving that. We found ourselves behind in a rat race with a handful of competitors. Our runway was nearly depleted as we were spending almost all of our revenue on marketing, and we found ourselves at the intersection of the two most challenging spaces to build a startup: education and consumer. This combination, especially without a targeted niche, made it difficult to stand out in a crowded market.

For these reasons, we decided to explore new opportunities. But, as we were pivoting I realized we had little alignment on direction and ideas. It was clear that we fundamentally wanted different things from startups. His focus was to grow big and it didn't matter what he worked on while I wanted to solve problems meaningful to me. Eventually, I decided that splitting up was the right choice because our differences in values and goals would lead to unhappiness and waste both our time.

What I learned:​

• There's a lot of vanity metrics out there and oftentimes they don't paint the full picture
• It's way better to focus on a tighter niche
• Don't join a rat race unless you have a competitive advantage that will bring you to #1
• Aligning on goals and values are super important in a co-founder relationships

What I'm up to now.​

After breaking up with my co-founder, my immediate plan was to create boilerplate code for future startups, share it with folks, and earn a little bit of cash. But what I found was that I found real joy in helping these developers launch their startups. So now I'm on a mission to help developers build startups.

Here are some initiatives I've started in the past month:

• Compiled a personal list of startup resources
• Open-sourced my startup boilerplate code
• Created a discord community of entrepreneurial developers

There seems to be a lot of confusion with Riverpod and the way it is used. Admittedly the documentation is lacking. And for someone getting started, there are many decisions to be made like:

• Should I use code-generation?
• How many providers should I create?
• What should be contained in each provider?

Because of this adaptability, it can become very confusing for someone just getting started. I'm creating this blog post to lay some ground rules that I set for myself when using riverpod. If you're getting started with riverpod, following these rules will be a good starting point.

But before reading on these rules, I highly recommend you checkout these guides in this order:

1. Flutter Riverpod 2.0: The Ultimate Guide
2. How to Auto-Generate your Providers with Flutter Riverpod Generator
3. How to use Notifier and AsyncNotifier with the new Flutter Riverpod Generator

Basics​

Because I know some of you are lazy as hell, I'll summarize what I think is important in the below bullet points:

• Riverpod is like a global variable storage and each provider is it's own global variable.
• Only special widgets ConsumerWidget and ConsumerStatefulWidget have access to these providers.
• You can access the providers using ref.read and ref.watch
  • ref.watch is used in the Widget's build method rebuilds the widget the state changes
  • ref.read is used outside of the Widget's build method
• There are many different types of providers to choose from and the riverpod generator makes it so you don't need to choose which one to use.
• There are different modifiers you can apply to the provider when accessing it.
  • By default you get the AsyncValue with no modifiers
  • .notifier can be used to access the functions within the provider
  • .future can be used to get the latest value of the state asynchronously
• An AsyncValue is returned when accessing the provider with no modifiers
  • .when is typically used in the Widget build method
  • .value is to get the current value

Common Pitfalls of Riverpod​

Not Using Code Generation​

I personally hate code generation. It adds an extra generated file and it abstracts logic that might be important to understand.

Because of reasons above, I decided to give riverpod a try without code generation. After a couple of times, of choosing the wrong provider, encountering bugs because of incorrect parameters, I decided that code generation was the way forward.

After I gave it a shot, everything became simple. It saved me hours of hair pulling trying to configure the correct parameters for each provider. Even the riverpod documentation highly recommends code generation.

Grouping Providers based on Technology​

When first working with riverpod, I thought the best approach would be to group global variables by the technology. For example, I had a library for my database, I put all my database related functions in the single provider and called it a day. My thinking was that this was just a global variable storage

But by doing this, I lost a lot of the capabilities riverpod provided out of the box. I had to:

• Refresh the UI with ref.watch based on specific criteria
• I had to manage the states myself which added unnecessary complexity
• Handle the initialization of states and loading states manually

If you want to see how NOT to use riverpod, I encourage you to checkout how I did it incorrectly with Fleeting Notes.

Not Using Streams​

Streams are so so powerful. If you have a database that supports streaming I highly recommend you use streams to streamline your setup. There's no more need to handle updates, inserts, or deletes, they are automatically done so with your backend being the source of truth.

Examples​

Below are two very common use cases for production applications. One is with authentication and the second is with routing.

Authentication​

Below is a simplified version for learning purposes. Checkout the full code here.

@Riverpod(keepAlive: true)
class Auth extends _$Auth {
  // We use a stream controller to control when the stream is updated and what object is in the stream.
  final StreamController<AppUser?> authStateController =
      StreamController.broadcast();

  Auth();

  @override
  Stream<AppUser?> build() {
    // listen to auth state change
    final streamSub = client.auth.onAuthStateChange.listen((authState) async {
      refreshUser(authState);
    });

    // dispose the listeners
    ref.onDispose(() {
      streamSub.cancel();
      authStateController.close();
    });

    // return the stream
    return authStateController.stream;
  }

  supa.SupabaseClient get client => supa.Supabase.instance.client;

  Future<AppUser?> refreshUser(supa.AuthState state) async {
    final session = state.session;
    if (session == null) {
	  // set the auth state to null
      authStateController.add(null);
      return null;
    }

    // Make an additional query to get subscription data
    final metadata = await client
        .from("stripe")
        .select()
        .eq("user_id", session.user.id)
        .maybeSingle();

    // Put together custom user object
    final user = AppUser(
      session: session,
      authEvent: state.event,
      activeProducts: List<String>.from(metadata?["active_products"] ?? []),
      stripeCustomerId: metadata?["stripe_customer_id"],
    );

    // update the stream
    authStateController.add(user);
    return user;
  }
}

Routing​

Below is a simplified version for learning purposes. Checkout the full code here.

// This is crucial for making sure that the same navigator is used
// when rebuilding the GoRouter and not throwing away the whole widget tree.
final navigatorKey = GlobalKey<NavigatorState>();
Uri? initUrl = Uri.base; // needed to set intiial url state

@riverpod
GoRouter router(RouterRef ref) {
  // we watch the authState to update the route when auth changes
  final authState = ref.watch(authProvider);
  return GoRouter(
    initialLocation: initUrl?.path, // DO NOT REMOVE
    navigatorKey: navigatorKey,
    redirect: (context, state) async {
      // we redirect the user based on different criteria of auth
      return authState.when(
        data: (user) {
          // build initial path
          String? path = initUrl?.path;
          final queryString = initUrl?.query.trim() ?? "";
          if (queryString.isNotEmpty && path != null) {
            path += "?$queryString";
          }
          // If user is not authenticated, direct to login screen
          if (user == null && path != '/login') {
            return '/login';
          }
          // If user is authenticated and trying to access login or loading, direct to home
          if (user != null && (path == '/login' || path == '/loading')) {
            return "/";
          }
          // After handling initial redirection, clear initUrl to prevent repeated redirections
          initUrl = null;
          return path;
        },
        error: (_, __) => "/loading",
        loading: () => "/loading",
      );
    },
    routes: <RouteBase>[
      GoRoute(
        name: 'loading',
        path: '/loading',
        builder: (context, state) {
          return const Center(child: CircularProgressIndicator());
        },
      ),
      GoRoute(
        name: 'login',
        path: '/login',
        builder: (context, state) {
          return const AuthScreen();
        },
      ),
      GoRoute(
        name: 'home',
        path: '/',
        builder: (context, state) {
          return const HomeScreen(title: "DevToDollars");
        },
      ),
    ],
  );
}

What's Next?​

If you liked what you saw, I encourage you to checkout my Flutter production boilerplate. This boilerplate doesn't only get you up and running in under 30 minutes, but also is a good resource if you're building your own app.

For the past 2 years I've been building startups and for my most recent startup I was able to reach 50k users in under 6 months. Throughout my journey, I've been consuming startup content like a fiend. These are the resources that helped me get to where I am today.

1. Before Startup​

General Startup:

• Should You Start A Startup? (Youtube)
• The Lean Startup Method (Book)
• The E-Myth Revisited (Book)
• Zero to One (Book)

Talking To Users:

• Eric Migicovsky - How to Talk to Users (Youtube)
• The Mom Test (Book)

Startup Ideas:

• Where Do Great Startup Ideas Come From? (Youtube)
• Kevin Hale - How to Evaluate Startup Ideas (Youtube)
• Avoid these Tempting Startup Ideas (Youtube)
• How to get startup ideas (Youtube)

2. Initial Enthusiasm​

Building MVP:

• Michael Seibel - How to Plan an MVP (Youtube)
• How to Build an MVP (Youtube)
• Running Lean (Book)

Co-founder / Relationships:

• How to find the right co-founder (Youtube)
• Kevin Hale - How to Work Together (Youtube)
• Non-Violent Communication (Book)
• YC Co-Founder Matching (Platform)

Getting Customers / Launching:

• How to Get Your First Customers (Youtube)
• Kat Manalac - How to Launch (Again and Again) (Youtube)
• Traction (Book)

3. Reality Sets In​

• The Hard Thing About Hard Things (Book)
• The Cold Start Problem (Book)
• Founders at Work (Book)
• How to Build the Future (Youtube)
• Founder Networking Events (Platform)

4. Experimenting & Pivoting​

Time Management / Productivity:

• Adora Cheung - How to Prioritize Your Time (Youtube)
• Startup Experts Reveal Their Top Productivity Advice (Youtube)

Marketing:

• The 1-Page Marketing Plan (Book)
• Twitter Growth Playbook (Blog)

Sales:

• How to Sell by Tyler Bosmeny (Youtube)
• Spin Selling (Book)
• Gap Selling (Book)

Analytics:

• Ilya Volodarsky - Analytics for Startups (Youtube)
• Kevin Hale - How to Improve Conversion Rates (Youtube)
• Lean Analytics (Book)

Design:

• Refactoring UI (Book)

5. Starts Working​

Growth:

• Hacking Growth (Book)
• Dalton Caldwell - All About Pivoting (Youtube)
• Gustaf Alströmer - Growth for Startups (Youtube)
• Kevin Hale - Startup Pricing 101 (Youtube)

Raising Capital:

• Should Your Startup Bootstrap or Raise Venture Capital? (Youtube)
• The Hacker's Guide to Investors (Blog)
• Why Founder's Shouldn't Think Like Investors (Youtube)

6. Product Market Fit & Scaling​

• The Hard Thing About Hard Things (Book)
• Founders at Work (Book)
• The Cold Start Problem (Book)
• Tim Brady - Building Culture (Youtube)
• Ali Rowghani - How to Lead (Youtube)

Other Resources​

• Dalton & Michael Show
• YC Startup School: 2017, 2018, 2019, 2020, 2023/24
• Paul Graham Essays
• Startup Playbook by Sam Altman

Flutter for web has evolved significantly in the past few years and in this post I wanted to give a comprehensive comparison between using Flutter vs React for developing web apps specifically. I've used both Flutter and React for startups so I have a good sense of both.

Anyways, the most important thing in startups is iteration speed. The ability to quickly build a product, get customer feedback, and iterate is the thing that sets apart the good startups and the dead startups. Now in my opinion, a good framework (for startups), is one that enables you to iterate as fast as possible. With that knowledge, let's dive into why I think Flutter wins in almost all aspects.

Development Experience​

Flutter makes the dev life a breeze. Forget the headache of constant null checks, too many variables, and scratching your head over whether an empty array is truly empty. Dart’s tooling is just the cherry on top, making Flutter my go-to for a smooth coding experience.

✅ Flutter | ❌ Javascript

Setup Time​

Flutter is incredibly self-sufficient, providing a wealth of packages right out of the box. This eliminates the need for extensive research on UI libraries or the necessity of third-party libraries for basic functionalities. The ease of access to these tools significantly accelerates the development, allowing for fast iteration cycles.

✅ Flutter | ❌ Javascript

Transitioning to Mobile​

Although, we are comparing web frameworks, it's also important to note the ability to transition to a native mobile app. Mobile is becoming increasingly prevalent and users are not as tolerant with using web apps on their phone. With React, there is no easy way to transition to mobile and it comes with the logistical nightmare of managing separate codebases for different platforms. This is another easy win for Flutter.

✅ Flutter | ❌ Javascript

SEO and Initial Load Speeds​

Although not directly related to web apps, I wanted to bring SEO up because this is a contentious topic. React 100% takes this because Flutter is NOT built for static web pages. It has slow initial loading speeds and bad SEO. Now this begs the question: how does this affect my startup iteration speed?

It doesn't.

If you're building a startup, it's much faster to use a no-code landing page builder (e.g. Framer) to build your landing page. Then the landing page can have a call to action which will lead the user into clicking to the app.

❌ Flutter | ✅ Javascript

Hiring​

Some people worry that finding developers who know how to use Flutter might be hard because it's pretty new. This makes sense since not a lot of people have had the chance to learn Flutter yet.

But from what I've seen, it's not a big problem. Flutter is easy to learn and use. I once hired a college intern who only knew how to use React, and guess what? They were able to contribute to our Flutter projects after one week of onboarding.

So, if you're thinking of hiring someone, you don't need to find someone who only knows Flutter. Oftentimes, someone who knows JavaScript (a common programming language) can learn Flutter quickly and do a great job.

❌ Flutter | ✅ Javascript

In Summary​

Hey, I'm Matt, once the CTO of a startup backed by YC. Today, I'm here to unravel the steps I took to reach 50,000 users and how you can replicate this success!

1. Identifying a problem​

Everything began with a problem that needed solving. In my scenario, this was the tedious task med school students faced creating flashcards from their study material, dedicating precious hours each week to this alone.

2. Understanding my customers & competitors​

Understanding your customers means REALLY getting to know them. I took a trip to California, visiting Stanford and UCLA, to talk directly with over 50 med school students. Coupled with deep dives into online forums and Reddit, I gathered invaluable insights:

• Who are my users? They are med students in the U.S., buried under 70+ hours of study each week, all while preparing for the USMLE exam while doing their clinical placements. Improving their study efficiency by even 20% could save them invaluable hours.
• What is their current workflow? Although their study methods vary, they universally rely on question banks as a testing tool. The challenge here lies in ensuring they don’t repeat the same mistakes, which they tackle through various means like manual flashcards, Excel spreadsheets, or using complex software to track their progress.
• What does my product offer? I developed an AI-powered flashcard generator designed to seamlessly integrate into their study routine, allowing for the automatic creation of flashcards from their question bank questions with just a click. This innovation significantly streamlines their study process, eliminating the need for manual flashcard creation.

3. Validating my idea​

Before diving into product development, validating the idea was crucial. I crafted a Reddit post here that attracted over 90 upvotes which led to numerous direct messages. This was the first sign of potential success, but the true test is whether or not they would pay for it.

4. Building my landing page​

The decision to opt for a no-code webpage builder over Flutter for the landing page was influenced by three key reasons:

1. Flutter's shortcomings for landing pages, notably slower load times and subpar SEO capabilities.
2. Empowering my non-technical co-founder to make edits, significantly enhancing our agility in making iterations.
3. The fast speed of deployment offered by no-code solutions.

5. Web App Development​

With the landing page set up and the concept validated, I moved on to developing the web application. Opting to focus solely on a web app was driven by two considerations:

• Speed: Immediate deployment, avoiding the drawn-out approval processes associated with app stores, and the complications of mobile-specific setups.
• Accessibility: The universal ease of accessing a web link, simplifies user feedback and eliminates the need for app store downloads.

6. Iterating Based on Customer Feedback​

Following the launch, I reached out to the med students I initially spoke with, seeking their feedback. This step was critical, as their input directly influenced our prioritization of features, including the consideration of mobile support for future development. To date, we haven't added a mobile app, but it remains a goal on our roadmap.

7. Continuing to Grow​

For us, leveraging TikTok through partnerships with micro-influencers was a game-changer, generating viral content that led to spikes in users.

Throughout this journey, our strategy was to experiment, identify what worked, cut what didn’t, and double down on successful tactics.

What Now?​

Thanks for taking the time to read the post. I'm currently on a mission to help developers build their startups and I hope that my experience is helpful for you! If you want to build a startup with Flutter, checkout my open-source flutter boilerplate.

Through the years, I've come to realize that in the startup world, speed isn't just an advantage—it's the lifeline. As a former CTO of a YC-backed startup, having launched more than five apps—with the latest one hitting over $10K in revenue in under three months—I've witnessed the undeniable power of rapid iteration. This ability to quickly build, launch, gather feedback, and refine is what really distinguishes the seasoned entrepreneurs from the novices. It's what makes or breaks a startup.

With this in mind, I've found that Flutter stands out as the best tool for achieving quick iterations. In this blog post, I dive deep into why I believe in Flutter's capabilities. I'll share insights from my current startup's workflow using Flutter, discuss some challenges I've encountered along the way, and outline precisely why I consider it a superior choice for any startup looking to move quickly and efficiently.

My Typical Development cycle with Flutter as a Startup Founder​

From my experience, this workflow has been my go-to. Even for my current startup, I validated the idea with a Reddit post, then created a web app, and marketed and iterated based on customer feedback. I was able to go from idea to product to revenue in just under a week. You can do so too by following this approach. If you're curious about how I structured my code, check out my open-source Flutter boilerplate.

1. Idea Validation: Before doing the work, I like to test the waters. For example, I check popular posts on reddit to see if there's a genuine interest in my product. This step is critical—no point in building something that nobody wants.
2. Landing page with Framer: Next, I create a landing page that conveys what I want to sell. This will be the first touchpoint for potential customers, making it a critical step in validating the product's market fit.
3. Web App Development with Flutter: Once I'm sure that this is something people want, I start developing a web app using my open-source Flutter production boilerplate. Here’s why I start with only web in Flutter:
   • Speed: Deploying a web app is immediate, bypassing the lengthy approval times of app stores.
   • Accessibility: A web link is universal, making it easy for users to access and provide feedback without the barriers of downloading from an app store.
4. Iterate Based on Customer Feedback: This is where the magic happens. This step is iterative and ongoing, shaping the product to fit the users' needs perfectly.
5. Expanding to Mobile and Desktop: Only when there is demand, or I recognize a clear growth path through other platforms, do I consider expanding. Flutter’s cross-platform capability means that transitioning to other platforms is seamless. I treat this as another feature in the pipeline—important, but always prioritized alongside other development needs.
6. Unified Codebase, Continuous Iteration: With a single codebase, I continue to evolve the app, making enhancements and adding features based on user feedback and market trends. The beauty of Flutter means every iteration benefits all platforms simultaneously.

If you liked what you read above, I also wrote a more in-depth guide on how I reached 50k users with Flutter web.

Caveats with using Flutter​

Don't Use Flutter as Your Landing Page​

Flutter is a tool that enables the creation of apps across multiple platforms — phones, computers, and the web — from a single codebase. While it offers extensive capabilities, it's not without its limitations. Websites developed with Flutter can experience slower initial load times and poor SEO support. This primarily becomes an issue if you're considering Flutter for your landing page, where speed and discoverability are crucial.

Rather than leveraging Flutter for landing pages, a no-code tool like Framer can be a more efficient choice. This approach allowed me to quickly create a landing page that had SEO straight out of the box and saved me precious time as my non-technical team members were able to make changes to the website themselves.

Google's Poor Track Record​

Concerns about Google potentially discontinuing Flutter are not unfounded, given its history with other projects (as documented on killedbygoogle.com). However, my confidence in Flutter's longevity remains unshaken.

Here's why: Flutter addresses a significant gap in multi-platform development, offering a more streamlined process than its competitors. Additionally, its adoption is on the rise, with major companies like Alibaba, The New York Times, eBay, and Kijiji embracing Flutter for their applications.

Hiring for Flutter​

Some people worry that finding developers who know how to use Flutter might be hard because it's pretty new. This makes sense since not a lot of people have had the chance to learn Flutter yet.

But from what I've seen, it's not really a big problem. Flutter is quite easy to learn and use. I once hired a college intern who only knew how to use React (another way to make apps), and guess what? They were able to start helping out with our Flutter projects after just one week of onboarding. So, if you're thinking of hiring someone, you don't need to find someone who only knows Flutter. A lot of the time, someone who knows JavaScript (a common programming language) can learn Flutter quickly and do a great job. Plus, the language used in Flutter, called Dart, is easy to get if you already know JavaScript or Python. Dart combines the best parts of JavaScript and Python into something new and exciting

So, finding people to work on Flutter projects might seem tough at first because it's new, but it's actually not that bad. Many developers can pick it up quickly and start meaningfully contributing.

Dart (Flutter) vs Javascript​

Superior Development Experience​

With an understanding of Flutter’s limitations, it’s crucial to explore why I believe Flutter stands out as the premier choice for startups. First and foremost, Flutter offers exceptional language support and a developer experience that far surpasses its JavaScript counterparts.

With Dart, I'm spared the constant null checks, the decision paralysis between using undefined or null, and the confusion over the truthiness of an empty array. JavaScript's ambiguity and redundancy stem from its need to support legacy syntax, whereas Dart (and by extension, Flutter) learns from JavaScript’s missteps, presenting a cleaner, more intuitive language. In my opinion, the A class development experience makes learning and developing on Flutter much faster than it's JS counterpart.

Packages out-of-the-box​

Moreover, Flutter is incredibly self-sufficient, providing a wealth of packages right out of the box. This eliminates the need for extensive research on UI libraries or the necessity of third-party libraries for basic functionalities. The ease of access to these tools significantly accelerates the development process, allowing for swift iterations.

Single Codebase​

Perhaps the most significant advantage, however, is the ability to maintain a single codebase across multiple platforms. This feature is indispensable, especially for solo developers or small teams. The logistical nightmare of managing separate codebases for different platforms is a well-known pain point that Flutter elegantly solves. Plus, with more people using mobile devices these days, choosing to creating a mobile app vs only having a web app can give you a competitive edge.

Checkout my open-source Flutter Production Boilerplate​

Thanks for taking the time to read this! If you're thinking about using Flutter, I've got something that might help you out. Check out my open-source Flutter production boilerplate. It could save you more than 40 hours of setup time! Or, it might just be a good reference for you. It's packed with all the best tips and tricks I've learned from using Flutter for startups over the last 2 years. I really think it could be super useful for anyone looking to dive into Flutter.

Hi! My name is Matt. I'm a former CTO of a YC backed startup and I've built 2 apps in the past that have both generated over $10K USD of revenue.

Before moving onto my third startup, I wanted to take a step back, reflect on what I've done and create a good base for future startups. Which is why I've decided to write down my tech stack and create some boilerplate code for my future startups. I hope sharing this can help you build your startup!

Github Boilerplate Code

Development

• Frontend (Flutter)
  • State Management (riverpod)
  • Routing (go_router)
• Backend (Supabase)
  • Backend Functions (Deno)
  • Database (PostgreSQL)
• Payments (Stripe)
• Generative AI (OpenAI)
• Documentation (Gitbook)

DevOps

• CICD (Github Actions)
• Project Planning (Github Projects)
• Code Management (Github)

Design & UX

• Landing Page (Framer)
• Design (Canva)

Analytics & Monitoring

• Analytics (Posthog)
• Error Monitoring (Sentry)

Communications & Marketing

• Email API / SMTP (Postmark)
• Help Desk (Intercom)
• Community Management (Discord)

Productivity & Collaboration

• Quick Notes (Apple Notes)
• Notes & Documentation (ObsidianMD)
• Personal Task Management (Motion)
• Meetings (Google Meets)
• Emails (Superhuman)

Infrastructure & Hosting

• Web App Host (Netlify)
• Domain Management (Cloudflare)

Tools & Utilities

• IDE (iTerm2 / AstroNvim)
• Password Manager (1Password)
• Digital Workspace (Google Workspace)
• Video Editing (Descript)
• Quick Video Recording (Screen Studio)

Personal Setup

• Computer (M1 Macbook Pro 14")
• Browser (Arc)