ZEMOSO ENGINEERING STUDIO
September 20, 2022
7 min read

Docs, Guides, Resources: Getting developer microsites right in a product-led world

What do the Twillio’s, Stripe’s, Auth0’s, and Plaid’s of the world have in common? 

Apart from their incredible valuations, all these companies have gotten one thing spectacularly right. Despite being fairly complex offerings, the time taken before a user starts to see value from using the solution is incredibly low. 

And this (in no small measure) is because of the fantastic developer-friendly repertoire they have on offer. From well-architected microsites to splendidly put-together software development kits (SDKs) — these product owners and founders knew how important developers would be to their deployment and usage ecosystem and brought them along for the ride, from Day 1. 

To do justice (and out of fear of our product teams) to the topic, we’ll focus this particular post on the role a dev microsite can play in your product-led growth strategy, how to get it right, and how our teams have cracked the code to building some of the most well-used dev microsites. We’ll cover SDKs in the next post. 

Dev microsites are also called developer documentation, developer resources, documentation and resources, and so many other terms. But dev microsite just seems more suitable - no?

The truth: the fundamentals of running a lean operation means having to pick favorites, prioritizing ruthlessly, and sometimes putting certain things on the back burner. Let us tell you, and we learned this from some of the most successful serial entrepreneurs of our time: your developer microsite can't be one of the things you put on the back burner. So, at the risk of wasting precious digital real estate on something you already know, here’s a quick run-down of the benefits:

  When done right, a dev microsite is the chameleon of your product-led strategy: your sales collateral, your how-to-guide, your investor pitch expansion, and so much more. 

  It reduces time to realization of value, by facilitating self-service and pre-emptively overcoming objections and roadblocks. 

  When used well, it can shorten feedback cycles, and evolution cycles for the product itself. 

●   It drives up usage, exploration, and encourages expanding applications.

  It gives you a single, verified, straight-from-the-horse’s mouth point of truth to refer to at all times, removing unnecessary frustrations involved in long wait times, superfluous assumptions, and wasteful interpretations. ‍

If you still aren’t convinced, here’s the rest of the article. 

The evolutionary journey map of a developer microsite

By nature, a dev microsite’s role in your product marketing journey is evolutionary. In early-early stages, it articulates value most comprehensively to investors and early adopters. In the early adoption stage, it shortens feedback lifecycles and convinces the skeptics. In the growth stage, it is a crucial cog in the brand manager’s playbook, an essential vehicle to drive retention, and a critical driver of product-led growth. In the later expansion and traction stage, it’s what recaps familiarity for the little guys, creates belongingness for the newcomers, and becomes the bedrock for your developer community, allowing and creating an organic space to naturally discover the next big thing for your product. 

There’s a story that we often hear in the marketing world: about allowing user-led change to take its course. This one is about LEGO®, and anyone who’s been to any school for a marketing degree has probably heard the myth. As legend has it, in the early hyper-popularity phase of LEGO®’s life, some enthusiasts started using LEGO® blocks to go off the scripted path. Instead of building what’s on the box, they started getting really creative and building all kinds of new, never-been-done-before things. They posted videos of this on YouTube and those became viral. 

This story is not unlike the Coke case study, it has been retold so many times, nobody quite remembers what really happened, but everyone agrees on this. 

As LEGO® users got more and more creative with the building blocks, LEGO® had a couple of ways forward. They could “Cease and Desist”, claim the LEGO® trademark, and stop. Or, they could do what they did and build a whole co-creation community around this offshoot, productize it, and transform it into an experience by itself. Evidently, the latter path was taken. 

What happened organically for LEGO® and was a strategic masterstroke in hindsight is yours to build proactively with your developer microsite, opening a communication gateway to iterative brilliance and shared experiences. 

Getting creative with LEGO® blocks

But, don’t take our word for it. 

Absolutely not! 

But do take the word of serial entrepreneurs who have had Andreessen Horowitz invest in them, who went from $0 to $26 million in valuation in under a year, or who raised over $70 million in the course of two years. Apart from having a product that nailed the problem-solution, they all prioritized the ease-of-deployment experience. Even when the products were incredibly complex, finding the right thing to do to get to a value always seemed simple. 

We worked on their dev microsites through its various evolutionary cycles, and at different times, the microsites were a part of the user, deployer, and buyer journeys. We built these websites in parallel to the product and used different strategies based on how complex the actual exercise of deploying the product would be. 

For a fairly complex Data SecurityTech product, our dev microsite came equipped with a sandbox for developers to experiment with the solution and get a feel for it. For a simpler-to-implement solution, it became a how-to-guide to get the most out of various integrations and capabilities of the solution. For a HealthTech client, it was built with reusable components to make it as close to the actual product experience, focusing on the simplicity of use and deployment. 

Guides, resources, and documents for developer microsite

So, here’s our (not so) secret sauce to creating the best Dev Microsites out there. 

  Build it parallelly to the product so that you have everything documented, pre-set, and already on a self-sustaining model from the first day. An example of someone who’s done this better than anyone else: Google’s API/SDK reference documentation. It’s set up so that they can deprecate/add new interfaces parallelly. The Google Android docs keep changing, and is one of our favorites to go to for inspiration.

   Pay attention and build your dev microsite architecture to mirror your product architecture: modular, scalable, and containerized. For this one too, we go back to Google’s clarity in doc setups. They're incredibly large, complicated, but are easy to scale and we can't imagine their developers waiting for their turn to release updates to these as they simultaneously work on so many, many things.

   Take the DevOps lessons to your microsite: ensure that developers are able to create, and move updates to deployment quickly, at which point, you have a pre-set auto-check and auto-publish protocol in place to ensure easy roll-outs. (Don’t forget to build provisions for roll-backs.)

One of our favorites here, Skyflow’s developer documentation. They are growing super fast, rolling out new capabilities at epic speeds to keep up with their speed of scale, and have independent teams who’re working on various aspects of their solution. And their dev microsite doesn’t miss a thing: because they use a tried-and-tested protocol that empowers individual dev functional units to push out their docs alongside their features.  

   In the early stages, custom building isn't essential, so minimalist build solutions from Redocly, Changelog.md will work just fine. However, as your solution increases in complexity, being able to customize and use multi-media formats is going to be key to keeping the microsite relevant and current. Transition to a customizable, built from scratch system then to remove roadblocks.

We’ve learned this one the hard way so that you don’t have to: the branding requisitions around developer documentation is low in the early stages, and taking away resources from product build to custom build a developer microsite on a budget is unnecessary. However, as the product grows, sticking to that low-lift microsite and not evolving it can be detrimental and lead to longer buy cycles because, believe it or not, your developer microsite is a part of that buyer journey.  

   Work with partners who can speed up build and deployment for these. For example, depending on product lifecycle stage and complexity, Zemoso has their own pre-built templates that we can easily customize, white label, and deploy for our customers. 

More specifically, we have a microsite template with in-built mdx and API docs support. Any new customer can have their developer documentation up and running in three weeks with a sufficient amount of white labeling saving precious go-to-market time.

   Show, don’t tell where possible. Infographics, flow-charts, and intuitive symbolization are amazing and your developers will thank you for them. Ensure that visual representations match across your microsite and product user experience. 

The best example for this one is, of course, Stripe. They offer an amazing developer experience with their sample apps for workflows and checkouts. This link shows a sample user interface (UI) with respective platform code within the docs, making dev life super easy.

   Don’t assume knowledge of niche tech terminology. A one-phrase explanation with a hyperlink hurts no one. A clear articulation of use case is your best friend. Leading with what a developer might want to accomplish and jobs to be done, as opposed to: how to do something will be transformational. And even companies as large as Visa, follow this rule. They have so many different fintech terminologies in their docs and they hyperlink each one of them to allow easy exploration, supremely helpful for developers, even if they’ve been in the space for ages. 

At Zemoso Labs, we've made developer microsites and documentation a part of our engineering offering. Schedule a conversation with us today to learn more.


ZEMOSO ENGINEERING STUDIO

Docs, Guides, Resources: Getting developer microsites right in a product-led world

September 20, 2022
7 min read

What do the Twillio’s, Stripe’s, Auth0’s, and Plaid’s of the world have in common? 

Apart from their incredible valuations, all these companies have gotten one thing spectacularly right. Despite being fairly complex offerings, the time taken before a user starts to see value from using the solution is incredibly low. 

And this (in no small measure) is because of the fantastic developer-friendly repertoire they have on offer. From well-architected microsites to splendidly put-together software development kits (SDKs) — these product owners and founders knew how important developers would be to their deployment and usage ecosystem and brought them along for the ride, from Day 1. 

To do justice (and out of fear of our product teams) to the topic, we’ll focus this particular post on the role a dev microsite can play in your product-led growth strategy, how to get it right, and how our teams have cracked the code to building some of the most well-used dev microsites. We’ll cover SDKs in the next post. 

Dev microsites are also called developer documentation, developer resources, documentation and resources, and so many other terms. But dev microsite just seems more suitable - no?

The truth: the fundamentals of running a lean operation means having to pick favorites, prioritizing ruthlessly, and sometimes putting certain things on the back burner. Let us tell you, and we learned this from some of the most successful serial entrepreneurs of our time: your developer microsite can't be one of the things you put on the back burner. So, at the risk of wasting precious digital real estate on something you already know, here’s a quick run-down of the benefits:

  When done right, a dev microsite is the chameleon of your product-led strategy: your sales collateral, your how-to-guide, your investor pitch expansion, and so much more. 

  It reduces time to realization of value, by facilitating self-service and pre-emptively overcoming objections and roadblocks. 

  When used well, it can shorten feedback cycles, and evolution cycles for the product itself. 

●   It drives up usage, exploration, and encourages expanding applications.

  It gives you a single, verified, straight-from-the-horse’s mouth point of truth to refer to at all times, removing unnecessary frustrations involved in long wait times, superfluous assumptions, and wasteful interpretations. ‍

If you still aren’t convinced, here’s the rest of the article. 

The evolutionary journey map of a developer microsite

By nature, a dev microsite’s role in your product marketing journey is evolutionary. In early-early stages, it articulates value most comprehensively to investors and early adopters. In the early adoption stage, it shortens feedback lifecycles and convinces the skeptics. In the growth stage, it is a crucial cog in the brand manager’s playbook, an essential vehicle to drive retention, and a critical driver of product-led growth. In the later expansion and traction stage, it’s what recaps familiarity for the little guys, creates belongingness for the newcomers, and becomes the bedrock for your developer community, allowing and creating an organic space to naturally discover the next big thing for your product. 

There’s a story that we often hear in the marketing world: about allowing user-led change to take its course. This one is about LEGO®, and anyone who’s been to any school for a marketing degree has probably heard the myth. As legend has it, in the early hyper-popularity phase of LEGO®’s life, some enthusiasts started using LEGO® blocks to go off the scripted path. Instead of building what’s on the box, they started getting really creative and building all kinds of new, never-been-done-before things. They posted videos of this on YouTube and those became viral. 

This story is not unlike the Coke case study, it has been retold so many times, nobody quite remembers what really happened, but everyone agrees on this. 

As LEGO® users got more and more creative with the building blocks, LEGO® had a couple of ways forward. They could “Cease and Desist”, claim the LEGO® trademark, and stop. Or, they could do what they did and build a whole co-creation community around this offshoot, productize it, and transform it into an experience by itself. Evidently, the latter path was taken. 

What happened organically for LEGO® and was a strategic masterstroke in hindsight is yours to build proactively with your developer microsite, opening a communication gateway to iterative brilliance and shared experiences. 

Getting creative with LEGO® blocks

But, don’t take our word for it. 

Absolutely not! 

But do take the word of serial entrepreneurs who have had Andreessen Horowitz invest in them, who went from $0 to $26 million in valuation in under a year, or who raised over $70 million in the course of two years. Apart from having a product that nailed the problem-solution, they all prioritized the ease-of-deployment experience. Even when the products were incredibly complex, finding the right thing to do to get to a value always seemed simple. 

We worked on their dev microsites through its various evolutionary cycles, and at different times, the microsites were a part of the user, deployer, and buyer journeys. We built these websites in parallel to the product and used different strategies based on how complex the actual exercise of deploying the product would be. 

For a fairly complex Data SecurityTech product, our dev microsite came equipped with a sandbox for developers to experiment with the solution and get a feel for it. For a simpler-to-implement solution, it became a how-to-guide to get the most out of various integrations and capabilities of the solution. For a HealthTech client, it was built with reusable components to make it as close to the actual product experience, focusing on the simplicity of use and deployment. 

Guides, resources, and documents for developer microsite

So, here’s our (not so) secret sauce to creating the best Dev Microsites out there. 

  Build it parallelly to the product so that you have everything documented, pre-set, and already on a self-sustaining model from the first day. An example of someone who’s done this better than anyone else: Google’s API/SDK reference documentation. It’s set up so that they can deprecate/add new interfaces parallelly. The Google Android docs keep changing, and is one of our favorites to go to for inspiration.

   Pay attention and build your dev microsite architecture to mirror your product architecture: modular, scalable, and containerized. For this one too, we go back to Google’s clarity in doc setups. They're incredibly large, complicated, but are easy to scale and we can't imagine their developers waiting for their turn to release updates to these as they simultaneously work on so many, many things.

   Take the DevOps lessons to your microsite: ensure that developers are able to create, and move updates to deployment quickly, at which point, you have a pre-set auto-check and auto-publish protocol in place to ensure easy roll-outs. (Don’t forget to build provisions for roll-backs.)

One of our favorites here, Skyflow’s developer documentation. They are growing super fast, rolling out new capabilities at epic speeds to keep up with their speed of scale, and have independent teams who’re working on various aspects of their solution. And their dev microsite doesn’t miss a thing: because they use a tried-and-tested protocol that empowers individual dev functional units to push out their docs alongside their features.  

   In the early stages, custom building isn't essential, so minimalist build solutions from Redocly, Changelog.md will work just fine. However, as your solution increases in complexity, being able to customize and use multi-media formats is going to be key to keeping the microsite relevant and current. Transition to a customizable, built from scratch system then to remove roadblocks.

We’ve learned this one the hard way so that you don’t have to: the branding requisitions around developer documentation is low in the early stages, and taking away resources from product build to custom build a developer microsite on a budget is unnecessary. However, as the product grows, sticking to that low-lift microsite and not evolving it can be detrimental and lead to longer buy cycles because, believe it or not, your developer microsite is a part of that buyer journey.  

   Work with partners who can speed up build and deployment for these. For example, depending on product lifecycle stage and complexity, Zemoso has their own pre-built templates that we can easily customize, white label, and deploy for our customers. 

More specifically, we have a microsite template with in-built mdx and API docs support. Any new customer can have their developer documentation up and running in three weeks with a sufficient amount of white labeling saving precious go-to-market time.

   Show, don’t tell where possible. Infographics, flow-charts, and intuitive symbolization are amazing and your developers will thank you for them. Ensure that visual representations match across your microsite and product user experience. 

The best example for this one is, of course, Stripe. They offer an amazing developer experience with their sample apps for workflows and checkouts. This link shows a sample user interface (UI) with respective platform code within the docs, making dev life super easy.

   Don’t assume knowledge of niche tech terminology. A one-phrase explanation with a hyperlink hurts no one. A clear articulation of use case is your best friend. Leading with what a developer might want to accomplish and jobs to be done, as opposed to: how to do something will be transformational. And even companies as large as Visa, follow this rule. They have so many different fintech terminologies in their docs and they hyperlink each one of them to allow easy exploration, supremely helpful for developers, even if they’ve been in the space for ages. 

At Zemoso Labs, we've made developer microsites and documentation a part of our engineering offering. Schedule a conversation with us today to learn more.


Recent Publications
Why Realm trumps SQLite as database of choice for complex mobile apps — Part 2
Why Realm trumps SQLite as database of choice for complex mobile apps — Part 2
October 13, 2022
Testing what doesn’t exist with a Wizard of Oz twist
Testing what doesn’t exist with a Wizard of Oz twist
October 12, 2022
Beyond methodologies: Five engineering do's for an agile product build
Beyond methodologies: Five engineering do's for an agile product build
September 5, 2022
Zemoso’s next big move: Entering Europe with new offices open in London
Zemoso’s next big move: Entering Europe with new offices open in London
August 29, 2022
Drone Technology: The upswing in its usage and value realization in EnergyTech
Drone Technology: The upswing in its usage and value realization in EnergyTech
August 10, 2022
Winning first place at O'Reilly Media’s Architectural Katas — Spring 2022
Winning first place at O'Reilly Media’s Architectural Katas — Spring 2022
July 13, 2022
How to remix Amazon’s Working Backwards with Google’s Venture’s User Journey: The Dr. Strange Way
How to remix Amazon’s Working Backwards with Google’s Venture’s User Journey: The Dr. Strange Way
June 14, 2022
How we built a big data platform for a futuristic AgriTech product
How we built a big data platform for a futuristic AgriTech product
June 3, 2022
Why Realm trumps SQLite as database of choice for complex mobile apps — Part 2
Why Realm trumps SQLite as database of choice for complex mobile apps — Part 2
October 13, 2022
Testing what doesn’t exist with a Wizard of Oz twist
Testing what doesn’t exist with a Wizard of Oz twist
October 12, 2022
Beyond methodologies: Five engineering do's for an agile product build
Beyond methodologies: Five engineering do's for an agile product build
September 5, 2022
Zemoso’s next big move: Entering Europe with new offices open in London
Zemoso’s next big move: Entering Europe with new offices open in London
August 29, 2022
Drone Technology: The upswing in its usage and value realization in EnergyTech
Drone Technology: The upswing in its usage and value realization in EnergyTech
August 10, 2022
ZEMOSO ENGINEERING STUDIO
September 20, 2022
7 min read

Docs, Guides, Resources: Getting developer microsites right in a product-led world

What do the Twillio’s, Stripe’s, Auth0’s, and Plaid’s of the world have in common? 

Apart from their incredible valuations, all these companies have gotten one thing spectacularly right. Despite being fairly complex offerings, the time taken before a user starts to see value from using the solution is incredibly low. 

And this (in no small measure) is because of the fantastic developer-friendly repertoire they have on offer. From well-architected microsites to splendidly put-together software development kits (SDKs) — these product owners and founders knew how important developers would be to their deployment and usage ecosystem and brought them along for the ride, from Day 1. 

To do justice (and out of fear of our product teams) to the topic, we’ll focus this particular post on the role a dev microsite can play in your product-led growth strategy, how to get it right, and how our teams have cracked the code to building some of the most well-used dev microsites. We’ll cover SDKs in the next post. 

Dev microsites are also called developer documentation, developer resources, documentation and resources, and so many other terms. But dev microsite just seems more suitable - no?

The truth: the fundamentals of running a lean operation means having to pick favorites, prioritizing ruthlessly, and sometimes putting certain things on the back burner. Let us tell you, and we learned this from some of the most successful serial entrepreneurs of our time: your developer microsite can't be one of the things you put on the back burner. So, at the risk of wasting precious digital real estate on something you already know, here’s a quick run-down of the benefits:

  When done right, a dev microsite is the chameleon of your product-led strategy: your sales collateral, your how-to-guide, your investor pitch expansion, and so much more. 

  It reduces time to realization of value, by facilitating self-service and pre-emptively overcoming objections and roadblocks. 

  When used well, it can shorten feedback cycles, and evolution cycles for the product itself. 

●   It drives up usage, exploration, and encourages expanding applications.

  It gives you a single, verified, straight-from-the-horse’s mouth point of truth to refer to at all times, removing unnecessary frustrations involved in long wait times, superfluous assumptions, and wasteful interpretations. ‍

If you still aren’t convinced, here’s the rest of the article. 

The evolutionary journey map of a developer microsite

By nature, a dev microsite’s role in your product marketing journey is evolutionary. In early-early stages, it articulates value most comprehensively to investors and early adopters. In the early adoption stage, it shortens feedback lifecycles and convinces the skeptics. In the growth stage, it is a crucial cog in the brand manager’s playbook, an essential vehicle to drive retention, and a critical driver of product-led growth. In the later expansion and traction stage, it’s what recaps familiarity for the little guys, creates belongingness for the newcomers, and becomes the bedrock for your developer community, allowing and creating an organic space to naturally discover the next big thing for your product. 

There’s a story that we often hear in the marketing world: about allowing user-led change to take its course. This one is about LEGO®, and anyone who’s been to any school for a marketing degree has probably heard the myth. As legend has it, in the early hyper-popularity phase of LEGO®’s life, some enthusiasts started using LEGO® blocks to go off the scripted path. Instead of building what’s on the box, they started getting really creative and building all kinds of new, never-been-done-before things. They posted videos of this on YouTube and those became viral. 

This story is not unlike the Coke case study, it has been retold so many times, nobody quite remembers what really happened, but everyone agrees on this. 

As LEGO® users got more and more creative with the building blocks, LEGO® had a couple of ways forward. They could “Cease and Desist”, claim the LEGO® trademark, and stop. Or, they could do what they did and build a whole co-creation community around this offshoot, productize it, and transform it into an experience by itself. Evidently, the latter path was taken. 

What happened organically for LEGO® and was a strategic masterstroke in hindsight is yours to build proactively with your developer microsite, opening a communication gateway to iterative brilliance and shared experiences. 

Getting creative with LEGO® blocks

But, don’t take our word for it. 

Absolutely not! 

But do take the word of serial entrepreneurs who have had Andreessen Horowitz invest in them, who went from $0 to $26 million in valuation in under a year, or who raised over $70 million in the course of two years. Apart from having a product that nailed the problem-solution, they all prioritized the ease-of-deployment experience. Even when the products were incredibly complex, finding the right thing to do to get to a value always seemed simple. 

We worked on their dev microsites through its various evolutionary cycles, and at different times, the microsites were a part of the user, deployer, and buyer journeys. We built these websites in parallel to the product and used different strategies based on how complex the actual exercise of deploying the product would be. 

For a fairly complex Data SecurityTech product, our dev microsite came equipped with a sandbox for developers to experiment with the solution and get a feel for it. For a simpler-to-implement solution, it became a how-to-guide to get the most out of various integrations and capabilities of the solution. For a HealthTech client, it was built with reusable components to make it as close to the actual product experience, focusing on the simplicity of use and deployment. 

Guides, resources, and documents for developer microsite

So, here’s our (not so) secret sauce to creating the best Dev Microsites out there. 

  Build it parallelly to the product so that you have everything documented, pre-set, and already on a self-sustaining model from the first day. An example of someone who’s done this better than anyone else: Google’s API/SDK reference documentation. It’s set up so that they can deprecate/add new interfaces parallelly. The Google Android docs keep changing, and is one of our favorites to go to for inspiration.

   Pay attention and build your dev microsite architecture to mirror your product architecture: modular, scalable, and containerized. For this one too, we go back to Google’s clarity in doc setups. They're incredibly large, complicated, but are easy to scale and we can't imagine their developers waiting for their turn to release updates to these as they simultaneously work on so many, many things.

   Take the DevOps lessons to your microsite: ensure that developers are able to create, and move updates to deployment quickly, at which point, you have a pre-set auto-check and auto-publish protocol in place to ensure easy roll-outs. (Don’t forget to build provisions for roll-backs.)

One of our favorites here, Skyflow’s developer documentation. They are growing super fast, rolling out new capabilities at epic speeds to keep up with their speed of scale, and have independent teams who’re working on various aspects of their solution. And their dev microsite doesn’t miss a thing: because they use a tried-and-tested protocol that empowers individual dev functional units to push out their docs alongside their features.  

   In the early stages, custom building isn't essential, so minimalist build solutions from Redocly, Changelog.md will work just fine. However, as your solution increases in complexity, being able to customize and use multi-media formats is going to be key to keeping the microsite relevant and current. Transition to a customizable, built from scratch system then to remove roadblocks.

We’ve learned this one the hard way so that you don’t have to: the branding requisitions around developer documentation is low in the early stages, and taking away resources from product build to custom build a developer microsite on a budget is unnecessary. However, as the product grows, sticking to that low-lift microsite and not evolving it can be detrimental and lead to longer buy cycles because, believe it or not, your developer microsite is a part of that buyer journey.  

   Work with partners who can speed up build and deployment for these. For example, depending on product lifecycle stage and complexity, Zemoso has their own pre-built templates that we can easily customize, white label, and deploy for our customers. 

More specifically, we have a microsite template with in-built mdx and API docs support. Any new customer can have their developer documentation up and running in three weeks with a sufficient amount of white labeling saving precious go-to-market time.

   Show, don’t tell where possible. Infographics, flow-charts, and intuitive symbolization are amazing and your developers will thank you for them. Ensure that visual representations match across your microsite and product user experience. 

The best example for this one is, of course, Stripe. They offer an amazing developer experience with their sample apps for workflows and checkouts. This link shows a sample user interface (UI) with respective platform code within the docs, making dev life super easy.

   Don’t assume knowledge of niche tech terminology. A one-phrase explanation with a hyperlink hurts no one. A clear articulation of use case is your best friend. Leading with what a developer might want to accomplish and jobs to be done, as opposed to: how to do something will be transformational. And even companies as large as Visa, follow this rule. They have so many different fintech terminologies in their docs and they hyperlink each one of them to allow easy exploration, supremely helpful for developers, even if they’ve been in the space for ages. 

At Zemoso Labs, we've made developer microsites and documentation a part of our engineering offering. Schedule a conversation with us today to learn more.


Recent Publications

ZEMOSO ENGINEERING STUDIO

Testing what doesn’t exist with a Wizard of Oz twist

October 12, 2022
7 min read
ZEMOSO ENGINEERING STUDIO

Beyond methodologies: Five engineering do's for an agile product build

September 5, 2022
6 min read
ZEMOSO ENGINEERING STUDIO

How we built a big data platform for a futuristic AgriTech product

June 3, 2022
8 min read
ZEMOSO NEWS

Zemoso Labs starts operations in Waterloo, Canada

May 25, 2022
5 min read
ZEMOSO ENGINEERING STUDIO

Honorable mention at O’Reilly’s Architectural Katas event

May 17, 2021
5 min read
ZEMOSO ENGINEERING STUDIO

Product dev with testable spring boot applications, from day one

May 4, 2021
5 min read
ZEMOSO ENGINEERING STUDIO

When not to @Autowire in Spring or Spring Boot applications

May 1, 2021
5 min read
ZEMOSO ENGINEERING STUDIO

Efficiently handle data and integrations in Spring Boot

January 24, 2021
5 min read
ZEMOSO ENGINEERING STUDIO

Our favorite CI/CD DevOps Practice: Simplify with GitHub Actions

October 25, 2020
5 min read
ZEMOSO ENGINEERING STUDIO

How to use BERT and DNN to build smarter NLP algorithms for products

February 14, 2020
12 min read
ZEMOSO ENGINEERING STUDIO

GraphQL — Why is it essential for agile product development?

April 30, 2019
12 min read
ZEMOSO ENGINEERING STUDIO

GraphQL with Java Spring Boot and Apollo Angular for Agile platforms

April 30, 2019
9 min read
ZEMOSO ENGINEERING STUDIO

Deploying Airflow on Kubernetes 

November 30, 2018
2 min read
ZEMOSO PRODUCT STUDIO

How to validate your Innovation: Mastering Experiment Design

November 22, 2018
8 min read
ZEMOSO PRODUCT STUDIO

Working Backwards: Amazon's Culture of Innovation: My notes

November 19, 2018
8 min read
ZEMOSO ENGINEERING STUDIO

Product developer POV: Caveats when building with Spark

November 5, 2018
2 min read

Want more best practices?

Access thought-leadership and best practice content across
the product development lifecycle

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

© 2021 Zemoso Technologies
Privacy Policy

Terms of Use
LinkedIn Page - Zemoso TechnologiesFacebook Page - Zemoso TechnologiesTwitter Account - Zemoso Technologies

© 2021 Zemoso Technologies
Privacy Policy

LinkedIn Page - Zemoso TechnologiesFacebook Page - Zemoso TechnologiesTwitter Account - Zemoso Technologies
October 31, 2022