Dion Almaer

Software, Development, Products

Developer Platform

The rise of the extensible app platforms

I was excited to see Kenneth and his team ship the public beta of the Stripe App platform:

I was excited to dive into it, as I know that the developer experience would be high quality, and I wasn’t proven wrong. Great CLI experience. Great docs. What you have come accustomed too. As I read through the anatomy of what you are able to do with apps, I could see a lot of similarities with Shopify’s app platform.

The body of a Shopify store

Let’s dive into some anatomy. When chatting with one of my favorite new PMs, Ben Sehl, he shared an analogy of how a store is like a body… a metaphor which I will now abuse to kingdom come:

When you create a Shopify store, you get a simple, yet fully functioning experience… like a human with simple attire, let’s call them Shopi. How do you want to take this base and make it your own?

The first step that products and platforms give you is the ability to tweak the look and feel. This is where you start with theming. You can dress up Shopi in many ways, and make them unique. You can make the clothing yourself, or you can find manufacturers (theme developers!) that have pre-built quality goods that you can then customize from there. As the platform matures, so does the supporting ecosystem.

Now, there is a lot that you can do with the look and feel, but you quickly find that you need richer customizations. This is when the app platform comes in (often called plugins/extensions). The platform controls what can be extended. Can you replace limbs? The heart? The brain? How do you do this in a way that doesn’t destroy the body? A great platform allows for layers of extensibility, which is as much art as science. This is the type of work I love doing, and I am excited to see Shopify continue to refine these layers.

Shopify Flow: Helping you automate workflow

Systems such as nervous, circulatory etc can be the glue that makes everything work well. This is the platform doing its job at regulating everything. Connecting things and making sure any one extension doesn’t blow things up. Acting as an engine for connectors and workflows like Shopify Flow.

If you look deeper at Shopify and the Stripe platform, you see a variety of surfaces that offer extension points… e.g. the Stripe Dashboard, or the Shopify Admin. These surfaces have specific extensions with rich context. They offer embeddable UI points, with building blocks to have your extensions fit in (e.g. components that feel consistent for the users of that surface). These extensible app platforms have a variety of surfaces. In Shopify, you can ship an app that enhances the Admin for merchants, or Checkout for users, and more.

NOTE: I was particularly excited to see that Stripe is using the open source remote-ui library that we created and use in Shopify:

Ok. So, at this point, Shopi, is looking great with awesome clothing, a bionic arm, Tony Stark’s heart, and AR glasses. But you may want to customize EVEN more. This is where custom storefronts come in for Shopify. You can tie into the nervous system still via API (GraphQL or REST), but the body can be entirely different… with you building many more layers as you eschew the defaults. It doesn’t even have to be a binary choice… you should be able to weave together custom and the core headful experience.

I look forward to a future where merchants can customize their own Shopi to be exactly what they need, working with the foundations that Shopify gives them, and the creativity and skill of the developer ecosystem to provide apps, themes, and custom storefront work.

I’m also excited to see more extensible app platforms such as Stripe’s, and we share ideas and technology to raise all of the boats.

Extensibility is going to go from changes to the appearance, to bionic improvements, to providing genetic modifications.

Agency developers are underrated

You hear about the developer who created Wordle, or who went on to found a large company, or contributed an open source project to the commons. You don’t often hear about the agency developer, and they are both important and often on their own journeys.

The Value of Agency

Agencies, and consultants, are out there helping make businesses a reality. They deliver expertise when it doesn’t exist in house. They quickly expand the workforce and when done right, leave employees better equipped for growth.

By working at multiple companies in a domain, they can bring learnings, just as employees do when they change companies as they journey through their career.

I have found that high quality agencies are true experts who have bet their business on your platform, understand your competition, and know what your users really want. They build true empathy on what it takes to be successful.

If a platform company doesn’t have programs that include agencies as a tier one cohort they are probably doing it wrong. Ask yourself:

  • Am I training the developers at agencies to have a great understanding of what my platform or product offers? If they are asked, or are given freedom to choose, what solution to build on… would they choose you?
  • Are these developers external advocates in the community? Is there a community for them to show their chops, be rewarded for their knowledge, and celebrated?
  • Does the business team at agencies understand your offering and are you supporting them so they can be an extended sales force for you?
  • Do you have agencies not only servicing customers directly, but also through self-service opportunities (e.g. building apps / extensions / themes)?

At Shopify for example, our agencies are a vital part of our ecosystem, working with us on a joint mission to be merchant obsessed as a way to improve commerce for all. As I have dived into the ecosystem I am constantly finding agencies who deeply understand commerce and our platform, and are at the heart of delivering for our merchants to make their experiences unique and high quality.

We often talk about learning the tech, and the product, but learning commerce is an important key, and agencies have a lot of that knowledge. And once you understand the domain, competition, and environment, opportunities are unlocked.

The Entrepreneurial Path

Many of the solo or small team entrepreneurial developers that I have met came from a past life working at a merchant or at agencies. That was the training ground for their knowledge.

I have seen some common patterns when getting to know our developers, including one very strong one:

“I worked at an agency working on commerce sites for $YEARS. I started to notice that several of our clients were asking for $FEATURE, so I decided that I would build a Shopify app that delivers the feature and enables any merchant the ability to unlock it!”

— Pat

This takes so much risk away from your app development. For one, you can do work for clients directly to prove things out, and this gives you a direct line to a customer with the clear need (else they wouldn’t pay!) Then by working with other merchants you can learn what needs to be customizable, and then when ready an app version unlocks scale. It’s nice to get paid decent money from a merchant to do guaranteed work, and it’s nice to get money whenever someone installs your app.

This is yet another example of the power of de-risking app development with Shopify.

Thank you agencies, and those of you working at them. You are at the heart of it all.

Others in the series:

The difference between Platforms and Ecosystems

tl;dr: “What’s the difference between a platform and an ecosystem?” This simple question resulted in an ecosystem strategy to connect sub-ecosystems that work on the Web. What if we lean in and deeply connect our tools, services, frameworks, and platforms….. and align on the right incentives for a healthy web?

I work in a product area of Google that is called Platforms and Ecosystems, and I sometimes reflect on the question “what’s the difference between a platform and an ecosystem?”

There are many, but I have found myself diving into the differences in complexity of a rich ecosystem.

With platforms we often think in layers, each layer building on each other, and the interfaces mostly being at the boundaries. This is a nice abstraction when done right, as it isn’t leaking all over the place.

The layers view of a platform

An ecosystem often forms on top of a platform, or if it gets connected enough, you get combinations. Sub-ecosystems form that have their own fractal view of the world, and they may connect with multiple technical platforms (e.g. the React ecosystem touching Web, iOS, Android, Desktop, ….).

The Web is complex enough that it is one of the canonical examples of an ecosystem that has many sub-ecosystems. You can even slice “the web” itself into pieces including the technical client platform that is embedded in almost every native platform there is (WebView anyone?) as well as the connected open Web, where many technical stacks are available to run as well.

A week ago, I had the pleasure of spending some time with representatives from major global CMSes, and they are a fantastic example of sub-ecosystems.

We spoke of ecosystem loops, and how an ecosystem has so many more connection points that are not restricted to layers, and are multi-directional.

These connection points, when strong, can enable a healthy web ecosystem. This realization has changed the way that we work, thinking about we can truly enable healthy connections.

Foundationally, we obviously want to build web platform APIs that work for as many ecosystems as possible, whilst also push the web. We also work to build clear guidance on web.dev that helps developers understand what is possible on the web across key pillars and principles. We want to deliver new and better tools that help you create, debug, and deliver actionable insights to you (e.g. DevTools, Lighthouse, CrUX).

Speak the right language

Lighthouse Stack Packs can speak your language

One of the problems we see, is that there is often an impedance mismatch between the layer of abstraction that a developer uses (e.g. using a particular framework, set of libraries, or backend infra) and the feedback that tools and services surface.

We are on a journey across our portfolio to fix this, and the best example is probably Lighthouse:

  • Lighthouse plugins allow you to build on the platform to offer your own audits and rulesets, enabling you to enforce you own criteria or requirements. For example, a framework may have important linting tests, or an ecommerce platform may have retail oriented audits.
  • Lighthouse Stackpacks bring an understanding of the ecosystem into the existing core rules. Don’t give generic guidance on next generation images when you could give custom guidance for particular plugins or point the developer to a setting in the admin console.

Elsewhere we are thinking of similar evolutions:

  • web.dev offers framework specific guidance, but what if the base guidance changed based on your needs?
  • There are many Chrome extensions for developers which extend DevTools, but what if there was a strong plugin API where knowledge can be brought to the core tools?

I am excited to work with the ecosystem to enable this kind of intelligence for our collective developers.

Show me the incentives!

We can make life much better for developers, but we have also learned that this isn’t enough to fully elevate the web together.

We want to see the flywheel moving nicely on the above ecosystem loops, with users engaging with high quality content from developers and their sites and platforms.

As platforms, how do we enable this outcome? It’s hard, but we have learned a lot from the work that the ecosystem did to move to HTTPS.

Moar TLS!

It may be hard to think back to the days when HTTPS wasn’t the norm, and only 30% of traffic was secured. How could we make it the vast majority? I remember hearing thought such as: “it can’t be done!”, “people just don’t actually care enough!”, “it’s too hard!”

In retrospect, it’s interesting to reflect on the parts and pieces that I think collectively drove things forward:

#1 Knowledge and Insights
There was a lot of content on *why* this is important, and *how* to do it. I remember it being really quite hard to do, and also waking up in a sweat on a couple of occasions with my brain racing: “did my certificate expire?“

#2 Tooling
The ecosystem jumped in to help make it MUCH easier. LetsEncrypt changed the game, and servers and hosts jumped in too.

#3 Demand
Now it’s easier, and it’s the right thing to do, but companies have huge backlogs. How do we make “the right thing to do” blindingly aligned to users and the company?

We need the right incentives, and this was the final puzzle piece. How do we reward developers that do the right thing? Some examples here are:

  • Browser UI surfacing quality: At first browsers changed their UI to highlight the good (e.g. showcase “secure”), and then…. over time…. deliberately…. switch to the point where the default is secure and we highlight the insecure
  • HTTPS required for API usage: WIth Service Workers, and powerful capabilities such as those being worked on via Project Fugu we need to make sure that we aren’t setting users up for attacks. This keeps our users secure, and also incentivizes developers to move to HTTPS to gain access to said APIs.
  • Acquisition: highly quality content is better for our users, so we want to make sure that Google Search is driving engagement to that content. When HTTP was added as a ranking factor we noticed an increase in adoption.
    It has been great to see the sum of the parts add up to the great adoption of HTTPS and we continue to push.

Moar Incentives!

How do we learn from HTTPS and bring this to the other areas of quality such as performance?

We will make sure that:

  • We will be clear about the metrics that we think represent quality
  • We will surface data and insights for developers and decision makers across our suite of products, and accessible for third party tooling solutions
  • We are very deliberate in carrots and sticks so everyone has time to plan
  • We will work with the sub-ecosystems so we can align on everything above so we row in the same direction. For example, if you are an established CMS provider, it isn’t solely important to track how many themes and plugins you have in your marketplace, but also note the quality of the output and how you can use said marketplace to share the same incentives (surfacing the right metrics etc).

How can we build connections that will strengthen us all? Do you see anything we should be doing? I am all ears.

The right thing to do, is the right thing to do.