Skip to content

Company Details

Shorebird (legally Code Town, Inc) is a Delaware C Corp, founded to foster adoption of multi-platform development globally. We were founded by some of the same team who built Flutter and Dart and use those as our vehicle.

Shorebird is the name of the street on which Flutter was created and is likely a placeholder name until we find a better one. Suggestions welcome.

Portable development is not the default. Most businesses spend twice, or three times what they need to to reach all their users. Google’s open source UI toolkit, Flutter has answered some of this need and made it possible to deliver high quality UIs to multiple screens at once. Other offerings, e.g. React Native, Cordova, Xamarin have also tried to solve part of this problem.

Today, developers receive an incomplete offering, one “thrown over the wall” by Google. Today, Flutter is constrained by Google’s development model and internal politics. JSON is the most popular way to talk over the network, yet Google’s Flutter offering has terrible support, since Google itself doesn’t use JSON internally. Flutter developers often fight terribly long build times, because Google itself uses a different source control, and different build system internally. Flutter apps by-default look Google-branded, because Flutter is tightly coupled to Google’s design language.

One of the most common questions asked about Flutter, is when will Google kill it? Google has a reputation for killing products (e.g. https://killedbygoogle.com/). If Google stopped Flutter tomorrow, there would be a mad scramble to pick up the pieces because many businesses and developers depend on it. This uncertainty need not be so. A foundation can, and should, be built around Flutter and its stakeholders more distributed. But a foundation is not enough. Foundations move slowly, often suffer from tight-budgets, administrative overhead, and design-by-committee. A company is also needed to set a direction, directly aligned with public customers rather than Google-internal ones, and deliver a golden path and value to users.

Someone needs to stand up for portable development. Build amazing, complete solutions for developers and businesses of all sizes with the goal to make high quality, portable development, the default. That someone is Shorebird.

Incentives matter. At sufficient scale, the team and community make decisions based on the incentives they operate under rather than direction from one person. Today, Flutter’s incentives are aligned around Google, not the wide world of developers who use Flutter.

Shorebird is about aligning incentives with those we serve in ways existing consultancies cannot, big Flutter users cannot, and Google cannot. High quality portable software is inevitable. But BigTech, little consultancies, and open source alone will not make it the default. The largest problems facing flutter, and high quality portable software writ-large, are ones that cannot be solved within any Big Tech, or large users of Flutter, but have to be done by a new upstart who is commercializing Flutter.

We’re doing this now, because Flutter is big enough. Most of the foundational technical problems are solved (language performance and tooling, graphics performance, ecosystem bootstrapping etc.) and what’s missing now is the critical relationships and commercial alignment with the interests of the common Flutter user. We are starting this journey by filling the gaps that we can best fill. That doesn’t mean we fill all the gaps ourselves. We become synonymous with Flutter by democratic means, because we’re the best and most aligned with developers, not by fiat.

Our mission is to make high-quality, portable software the default way to build for everyone.

We are most successful when we build things that only we can build. There are many things big tech cannot build due to incentives, and other companies cannot build due to know how. Our first product was Code Push, one of the most requested features in Flutter. We then built CI for Flutter, something many have built before, but most have built more generically than just Flutter. We are unique in that we sell only to Flutter developers and thus can build things specifically fit to their purposes. Over time our product suite will grow to be both specific to Flutter and highly integrated within itself. Our value to developers is productivity, completeness, quality and alignment with their needs.

We serve developers by making them more productive. When they use Shorebird, they don’t have to build or integrate as much themselves, they get further, faster. They can follow our golden path and use our managed solutions for their creation, sharing, testing, and deployment.

We serve businesses by making their developers more productive and providing them security and assurance to their investments. When they use Shorebird, they know they’re using something they can rely on and they can call when they need. They know that they’re buying best-in-class solutions. They know they’re buying from a business that will be here tomorrow, not just an open source project that may not be maintained. They know that their developers are more productive, and happier when using our solutions.

We believe in a world where building software once means it works everywhere, beautifully.

If we succeed, the majority of development is portable with high-quality outcomes. Today in the gaming world, developers reach for portable solutions first. This is both because those solutions produce the best outcomes the fastest and they let developers figure out the fun stuff first and the platforms later. In the future, app developers will also reach for Shorebird first, because we serve them and their interests, not the platform vendors. Shorebird will help them produce the best quality products, and know that they can take them to any device or any screen they need to, without needless rewrites.

In this future the Flutter ecosystem is rich and robust, not just Shorebird. There is a Flutter foundation, which Shorebird is a large part of. Flutter and Dart are successful across all the devices businesses care to reach, including desktop, web and servers. Shorebird is synonymous with Flutter, just like Confluent with Kafka, or Apollo with GraphQL today. Businesses confidently reach for portable software development from Shorebird first, knowing it’s the safe and supported choice.

In the future, the world around us has also shifted. We’re far from alone in this journey. There will be more platforms, there will be more OS vendors. The web will change in part through the popularity of an alternative portability solution. There is likely a Flutter browser or at least Flutter and the web have grown closer as two communities with similar goals. Flutter itself will no longer be a just-for-Google solution.

  • Developer productivity matters. Developers are the reason we exist, their success is our goal and we will always put them first.
  • Our best work is open by default. We believe in transparency and openness. We live in a big world. Shorebird (and Flutter) serve a global audience. We can’t always be in the room and so the best way to “set others up to succeed” is to write things down in the open. Open Source is what made Flutter successful (and web browsers before it) and will be what makes Shorebird successful.
  • Real artists ship. It’s more important to ship, be wrong and learn than to ship right the first time.
  • The future is bigger than the past. It’s more important to make a better tomorrow than worry about our present or past. At time of writing, there are only a few million Flutter developers. There are billions of people, and probably 100s of millions of developers in the future. We’re here to help them all.
  • Our developer empathy: Developers are our customers, we must empathize with them, talk to them, and solve problems for them.
  • Our belief in high-quality, portable software: Many today accept what the platform vendors offer, we don’t. We know software development can be better, and that developers shouldn’t repeat themselves, businesses shouldn’t spend 2x/3x what they need to, and customers shouldn’t suffer from divergent, half-as-good experiences with 2x the bugs. We believe better is possible, the world deserves it, and we can make it happen.
  • Our open-ness: we are private when we need to be (e.g. to protect customers, to protect employees or to protect trade secrets over the short term), but by default and over the long term, we are public when we can be to reach the widest audience and keep ourselves to good practices of behavior and integrity.

I feel proud to work here, because I believe I’m making developer’s lives better. Flutter has made developer’s lives better, but the next steps for Flutter couldn’t be taken inside Google. We can, and we will, and that will help more people produce awesome products and go home earlier to spend more time with their families, instead of writing a translation of their previous work into Kotlin, and then again in Swift, and again in TypeScript or Go or whatever.

Shorebird is a great place for self-starters, who know how to self-manage, and enjoy the freedom of remote work. People who like working with strong colleagues regardless of their physical location and are excited to solve problems for developers and businesses. Birders have a sense of quality, they care about their own work product and the tools they’re providing to others. We’re proud to empower our customers to do their best work. We’re proud to be a part of a larger community. We feel good at the end of the week that we’ve made the world a little better by empowering developers who in turn touch billions of lives every week.

Users of Shorebird should feel that they’ve picked products designed for their use cases and outcomes. That Shorebird is accessible to them in the way any good open source project would, and responds to their needs in the way a commercial product does. Users should feel safe, knowing that they’ve picked a solution that’s reliable and sustainable, that supports them throughout the lifetime of their product and they will get promoted for using, not wrist-slapped by their boss. Users also know that by betting on Flutter and Shorebird they’ve found themselves a career, because they know they can take their skills to any screen and any product, not just be limited to a specific mobile framework.

The emotional core of our work is empowerment. We serve developers. They will feel like they could build what we’ve built themselves, but they will choose to use our solutions because they are hiring us for a “job to be done.” We are not the end product they sell to their customers, and they will feel that having hired us they will get further, faster with better outcomes for themselves, their business and their users.

Eric worked mostly on web browsers before starting Flutter — something used globally by billions of people and built open source by persons from every corner of the globe. It taught him that there are truly brilliant and motivated people everywhere. Leading Flutter and Dart (including through pandemic lockdowns and the resulting work-from-home diaspora) showed him that remote-first can work and that people can do their best work when you don’t care where they live but rather what they get done. So that’s what we’re doing at Shorebird. Hiring the best people, wherever they are.

Remote also has its downsides, clearly. Culture is much harder. How do you build social experiences at work for those who want it? How do you build a unified understanding of what the company is (as things inevitably change) without being in the same room regularly? GitLab and others have written extensively on these challenges. So we don’t know, but we sure as heck are gonna try. The world is simply too big and too filled with talented people to limit our hiring to one location.

So far our (very early) learnings have reinforced our believe in remote-only, but made us question if async-only remote will work. We’re still learning.

  • Eric Seidel (@_eseidel), Founder & CEO — Founded Flutter before Shorebird. Was previously Director of Flutter and Dart at Google. Eric has been working on helping the world stop writing everything twice 20 years, including major contributions to WebKit, Safari, Blink and Chrome.

  • Bryan Oltman (@bryanoltman), Founding Engineer — Was previously Tech Lead on Google’s internal Flutter team and has extensive experience with enterprise usage of Flutter.

  • Tom Arra (@tom_arra), Operations Lead — Tom has been a member of the Flutter community since 2018 and has helped scale products and teams at companies like BMW and Very Good Ventures before joining Shorebird. He has over 15 years of experience in the software industry including being an engineering lead, and leading large teams in the product and engineering space.

  • Dawn Parzych (@dparzych), Marketing Lead — Dawn is a developer-focused marketing leader with expertise in developer tools and cloud. She has led major events and marketing initiatives at Cloudflare and LaunchDarkly, and has served as a volunteer organizer for DevOpsDays.

We don’t currently have managers, or plan to anytime soon. Everyone just reports to Eric. This will eventually break down at scale. While leading Flutter, Eric had 20+ direct reports before we added more managers. Managers are very useful for supporting people (checking in regularly, helping with onboarding, career development, etc), but can get in the way of constant direct coordination needed in small teams.

Right now we all just use Discord. We have email, but mostly we use that for communicating to the outside world or things which need a more permanent record. Everything else happens on Discord, and 90%+ in public channels.

Flutter started with daily stand-ups (capped to 5 minutes total) and kept those all the way until 30-40 people. It was a chance to promote daily coordination between members of the team and as we got larger (10+) help make sure individuals had resources to be unblocked and didn’t accidentally work on the same issues. I imagine we’ll find something similar for Shorebird (synchronous

or not) and may even do them publicly. We’ll see. For now we use the #standup channel on Discord to post what we’re working on each day.

We don’t have much process around this yet. In short, we trust you to make the right decisions for the company. I think GitLab has a very sane policy on this and we’ll likely adopt something similar.

I’ve spoken with many Flutter customers. They love Flutter, but still find pain using or adopting it within their businesses. Some of the top pains I’ve heard from existing Flutter enterprise teams are:

  • Mobile releasing is hard. Mobile releasing is harder than web. Maintaining lots of versions of apps (and associated backends) is hard. “Code Push” is one solution, but Google’s Flutter team has chosen not to invest in it. We should.
  • Keeping product and other stakeholders abreast of latest changes is hard. Some would like something akin to Vercel’s “Deploy Previews” for Flutter apps.
  • Teams share mobile code, would like to share backend code. Most shops write in Flutter for mobile and then a variety of languages for backends. Many have backends they would not fully re-write, so would need to plug in with existing other services.
  • Teams share mobile code, would like to share web code. Most shops write in Flutter for mobile and then React for the web.
  • Dart/Flutter builds are too long. Most often this doesn’t seem to be Dart or Flutter itself, but rather the mobile build systems, particularly when plugins are involved.
  • Hard to manage many apps. Coordinating updates (e.g. a logo) across multiple apps and multiple releases is hard, even with Flutter.
  • Crash reporting and analytics are “meh”. Existing solutions are not great for Flutter. Some complaints that Sentry doesn’t play nicely with lots of versions in the wild (assumes a model of servers or web with one or few live versions). Other complaints that existing analytics solutions don’t fully understand Flutter views (where the user has scrolled to, etc.).
  • Knowing what to use in the Flutter ecosystem is hard. Quality of the Flutter ecosystem is inconsistent. Platform availability within the Flutter ecosystem is inconsistent.
  • Testing Flutter apps (and mobile apps in general) is hard. Some have asked for something like Mobile.dev for Flutter apps. Particular trouble around testing “invasive” apps, such as ones which use system accessibility events.

If you’re reading this and think Shorebird sounds like a fun place to work, come check out our open roles or join our Discord.