Developer
Developer
Table of Contents
Ship engineers for your first API startup customers
Saurabh Sharma
CTO @ Rye
February 19, 2024
6 min read
Discover how to effectively onboard engineers for your first API startup customers. This guide provides insights into building a strong technical team, creating seamless integration experiences, and ensuring customer satisfaction from the start.
Building a B2B company?
While B2C companies are duking it out for consumer attention, B2B plays a different game.
Consumer plays are hard - you're chasing a vast sea of individual users, each with their own whims and preferences. It's a high-volume, high-variance play where the 'one-size-fits-all' approach rarely fits anyone perfectly. For example, in social app plays - one wisdom I've heard during my Reddit days was often that social networks are like lotteries. It's hard to try to catch lightning in a bottle.
Contrary to this, building a B2B business can be rewarding because it provides an opportunity to engage deeply in relationships and gain a comprehensive understanding of complex problems, which can then be effectively addressed.
B2C is casting the widest net, while B2B is often closer to fishing with the sharpest spear.
This post talks through the case study of one of Rye’s forward deployment partnerships where we got into the trenches and built our first integration with one of our early customers Komi.
While B2C companies are duking it out for consumer attention, B2B plays a different game.
Consumer plays are hard - you're chasing a vast sea of individual users, each with their own whims and preferences. It's a high-volume, high-variance play where the 'one-size-fits-all' approach rarely fits anyone perfectly. For example, in social app plays - one wisdom I've heard during my Reddit days was often that social networks are like lotteries. It's hard to try to catch lightning in a bottle.
Contrary to this, building a B2B business can be rewarding because it provides an opportunity to engage deeply in relationships and gain a comprehensive understanding of complex problems, which can then be effectively addressed.
B2C is casting the widest net, while B2B is often closer to fishing with the sharpest spear.
This post talks through the case study of one of Rye’s forward deployment partnerships where we got into the trenches and built our first integration with one of our early customers Komi.
While B2C companies are duking it out for consumer attention, B2B plays a different game.
Consumer plays are hard - you're chasing a vast sea of individual users, each with their own whims and preferences. It's a high-volume, high-variance play where the 'one-size-fits-all' approach rarely fits anyone perfectly. For example, in social app plays - one wisdom I've heard during my Reddit days was often that social networks are like lotteries. It's hard to try to catch lightning in a bottle.
Contrary to this, building a B2B business can be rewarding because it provides an opportunity to engage deeply in relationships and gain a comprehensive understanding of complex problems, which can then be effectively addressed.
B2C is casting the widest net, while B2B is often closer to fishing with the sharpest spear.
This post talks through the case study of one of Rye’s forward deployment partnerships where we got into the trenches and built our first integration with one of our early customers Komi.
Early Days in a B2B Play
The early days in a B2B startup can feel like being part of a special ops team. It's about understanding the unique pain points of your customers and often engineering a solution that feels tailor-made. You should feel less like a vendor and more like a partner in their success. If you've worked at a large company before, this can often feel like working with a sister team in your organization. Each company has its own interests and a partnership that begins with strategically aligned incentives.
Rye's Early Days
Rye is a new SaaS company. We want to move fast and build quickly for our customers features and systems they want. Our team at the time we acquired our early customers was fairly small ~ 6 engineers.
Early customers were a range of companies/individuals from highly motivated tech companies of different sizes to indie devs hacking on a side project. Some were largely self-motivated, while others required more assistance. You’ll often feel like this spectrum with your early customers. When building out our API, we were fortunate enough to be selective with our customers and use it to develop the vision of the API we initially set out to create. We chose projects that moved us in the direction of building our vision. I'd love to share the story here about our first large integration that Rye built with our customer Komi.
Rye is a new SaaS company. We want to move fast and build quickly for our customers features and systems they want. Our team at the time we acquired our early customers was fairly small ~ 6 engineers.
Early customers were a range of companies/individuals from highly motivated tech companies of different sizes to indie devs hacking on a side project. Some were largely self-motivated, while others required more assistance. You’ll often feel like this spectrum with your early customers. When building out our API, we were fortunate enough to be selective with our customers and use it to develop the vision of the API we initially set out to create. We chose projects that moved us in the direction of building our vision. I'd love to share the story here about our first large integration that Rye built with our customer Komi.
Rye is a new SaaS company. We want to move fast and build quickly for our customers features and systems they want. Our team at the time we acquired our early customers was fairly small ~ 6 engineers.
Early customers were a range of companies/individuals from highly motivated tech companies of different sizes to indie devs hacking on a side project. Some were largely self-motivated, while others required more assistance. You’ll often feel like this spectrum with your early customers. When building out our API, we were fortunate enough to be selective with our customers and use it to develop the vision of the API we initially set out to create. We chose projects that moved us in the direction of building our vision. I'd love to share the story here about our first large integration that Rye built with our customer Komi.
Backend to Client
So we selected a customer and forward-deployed our engineers so that we could fully experience building a complete end-to-end integration using our APIs. This decision was largely driven by the fact that our API was not self-service. When building an early-stage company, it doesn't have to be. There was no documentation, apart from our raw GraphQL schema documentation, and the relationship between different endpoints was only obvious to the engineers who built it.
Rye was primarily built with a backend use case in mind, designed to be used on the server-side. However, we knew early on that to reach end-shoppers directly and make integrations easier, we would need our API to be easily accessible via browsers and mobile apps.
The company we integrated with was also a very small team and unable to commit to building the integration right away on our fast-paced timeline, so this partnership was mutually beneficial. Rye would get to use our APIs to build a complete integration, at a relatively fast pace, and the customer would be able to deliver a large feature set without the required large commitment.
So we selected a customer and forward-deployed our engineers so that we could fully experience building a complete end-to-end integration using our APIs. This decision was largely driven by the fact that our API was not self-service. When building an early-stage company, it doesn't have to be. There was no documentation, apart from our raw GraphQL schema documentation, and the relationship between different endpoints was only obvious to the engineers who built it.
Rye was primarily built with a backend use case in mind, designed to be used on the server-side. However, we knew early on that to reach end-shoppers directly and make integrations easier, we would need our API to be easily accessible via browsers and mobile apps.
The company we integrated with was also a very small team and unable to commit to building the integration right away on our fast-paced timeline, so this partnership was mutually beneficial. Rye would get to use our APIs to build a complete integration, at a relatively fast pace, and the customer would be able to deliver a large feature set without the required large commitment.
So we selected a customer and forward-deployed our engineers so that we could fully experience building a complete end-to-end integration using our APIs. This decision was largely driven by the fact that our API was not self-service. When building an early-stage company, it doesn't have to be. There was no documentation, apart from our raw GraphQL schema documentation, and the relationship between different endpoints was only obvious to the engineers who built it.
Rye was primarily built with a backend use case in mind, designed to be used on the server-side. However, we knew early on that to reach end-shoppers directly and make integrations easier, we would need our API to be easily accessible via browsers and mobile apps.
The company we integrated with was also a very small team and unable to commit to building the integration right away on our fast-paced timeline, so this partnership was mutually beneficial. Rye would get to use our APIs to build a complete integration, at a relatively fast pace, and the customer would be able to deliver a large feature set without the required large commitment.
Your API doesn’t work
Our API was not designed for the front end and did not work on the front end. We were aware of this from the beginning, but building this initial customer integration taught us about the limitations of our API. We did not have a testing environment, documentation, guides, or simulated flows to facilitate test purchases. And those were just the obvious issues. As we built it, we realized how ill-equipped we were to support this use case.
Our API was not designed for the front end and did not work on the front end. We were aware of this from the beginning, but building this initial customer integration taught us about the limitations of our API. We did not have a testing environment, documentation, guides, or simulated flows to facilitate test purchases. And those were just the obvious issues. As we built it, we realized how ill-equipped we were to support this use case.
Our API was not designed for the front end and did not work on the front end. We were aware of this from the beginning, but building this initial customer integration taught us about the limitations of our API. We did not have a testing environment, documentation, guides, or simulated flows to facilitate test purchases. And those were just the obvious issues. As we built it, we realized how ill-equipped we were to support this use case.
Foundation for a forward deployment
There are a couple of things to highlight that can make forward deployments work well.
We embedded our engineers directly into the customer's team:
We used their task-tracking systems.
We had weekly check-ins.
We followed their deployment process.
We were added directly to their GitHub to commit code in their codebase.
Throughout this project, which required extensive client-side work, we maintained a close collaboration with the customer's designer. This allowed us to propose solutions and workarounds for technically challenging flows easily.
Scoped the integration, got sign-off
Before diving in, our engineers looked at the customer's codebase, made a quick prototype to scope out the changes involved, and highlighted unknowns.
We discussed major architecture decisions in advance, created a design document, and obtained clear sign-off from the engineers on the customer's team.
Set clear goals and deadlines
Instead of using this integration to build a full-blown product, we put on our growth hats and approached it as an experiment.
We outlined a clear product plan to test the hypothesis behind this integration and determine how we would measure the results.
A wonderful benefit of this approach is that it forces you to consider telemetry, and the results were valuable in proving the success of our partnership and holding us accountable for it.
This can also serve as a good sanity check.
With the design document, we defined the scope of the work and established a clear deadline for the integration.
We were, of course, mistaken about the target launch date and had to adjust the timeline. However, by explicitly communicating this and involving discussions, we ensured that all stakeholders were always on the same page.
Testing and Rollout Plans
The customer's QA made testing our integration easier. Many issues were caught.
We conducted a phased rollout, starting with the internal team/founders.
We rolled out to a select set of users.
We saw our customer IRL - With a remote-first team, this can be challenging, but businesses are still built on relationships. Having executive-level buy-in and making the effort to see customers is worthwhile. Honestly, it made both parties feel like we're not just a vendor; we're a real partner in this.
Also a note - we signed NDAs, of course, to do all of the above.
Alright - sounds easy, right?
There are a couple of things to highlight that can make forward deployments work well.
We embedded our engineers directly into the customer's team:
We used their task-tracking systems.
We had weekly check-ins.
We followed their deployment process.
We were added directly to their GitHub to commit code in their codebase.
Throughout this project, which required extensive client-side work, we maintained a close collaboration with the customer's designer. This allowed us to propose solutions and workarounds for technically challenging flows easily.
Scoped the integration, got sign-off
Before diving in, our engineers looked at the customer's codebase, made a quick prototype to scope out the changes involved, and highlighted unknowns.
We discussed major architecture decisions in advance, created a design document, and obtained clear sign-off from the engineers on the customer's team.
Set clear goals and deadlines
Instead of using this integration to build a full-blown product, we put on our growth hats and approached it as an experiment.
We outlined a clear product plan to test the hypothesis behind this integration and determine how we would measure the results.
A wonderful benefit of this approach is that it forces you to consider telemetry, and the results were valuable in proving the success of our partnership and holding us accountable for it.
This can also serve as a good sanity check.
With the design document, we defined the scope of the work and established a clear deadline for the integration.
We were, of course, mistaken about the target launch date and had to adjust the timeline. However, by explicitly communicating this and involving discussions, we ensured that all stakeholders were always on the same page.
Testing and Rollout Plans
The customer's QA made testing our integration easier. Many issues were caught.
We conducted a phased rollout, starting with the internal team/founders.
We rolled out to a select set of users.
We saw our customer IRL - With a remote-first team, this can be challenging, but businesses are still built on relationships. Having executive-level buy-in and making the effort to see customers is worthwhile. Honestly, it made both parties feel like we're not just a vendor; we're a real partner in this.
Also a note - we signed NDAs, of course, to do all of the above.
Alright - sounds easy, right?
There are a couple of things to highlight that can make forward deployments work well.
We embedded our engineers directly into the customer's team:
We used their task-tracking systems.
We had weekly check-ins.
We followed their deployment process.
We were added directly to their GitHub to commit code in their codebase.
Throughout this project, which required extensive client-side work, we maintained a close collaboration with the customer's designer. This allowed us to propose solutions and workarounds for technically challenging flows easily.
Scoped the integration, got sign-off
Before diving in, our engineers looked at the customer's codebase, made a quick prototype to scope out the changes involved, and highlighted unknowns.
We discussed major architecture decisions in advance, created a design document, and obtained clear sign-off from the engineers on the customer's team.
Set clear goals and deadlines
Instead of using this integration to build a full-blown product, we put on our growth hats and approached it as an experiment.
We outlined a clear product plan to test the hypothesis behind this integration and determine how we would measure the results.
A wonderful benefit of this approach is that it forces you to consider telemetry, and the results were valuable in proving the success of our partnership and holding us accountable for it.
This can also serve as a good sanity check.
With the design document, we defined the scope of the work and established a clear deadline for the integration.
We were, of course, mistaken about the target launch date and had to adjust the timeline. However, by explicitly communicating this and involving discussions, we ensured that all stakeholders were always on the same page.
Testing and Rollout Plans
The customer's QA made testing our integration easier. Many issues were caught.
We conducted a phased rollout, starting with the internal team/founders.
We rolled out to a select set of users.
We saw our customer IRL - With a remote-first team, this can be challenging, but businesses are still built on relationships. Having executive-level buy-in and making the effort to see customers is worthwhile. Honestly, it made both parties feel like we're not just a vendor; we're a real partner in this.
Also a note - we signed NDAs, of course, to do all of the above.
Alright - sounds easy, right?
Nightmares
Of course, a technical project of any sufficiently large scope only executes with hurdles. And boy, did we have our share.
Scope creep abundance
The biggest challenge in any project is dealing with scope creep abundance. The main issue when providing resources to end customers is the expansion of scope. This was the case for us, and it was especially worse because our team mostly focused on backend development.
We encountered major issues with an upstream vendor that were beyond our control. Instead of limiting the scope of the feature, we decided to implement workarounds for the issue. This significantly increased the scope of our initial integration. To put it into perspective, our 6-week project turned into a nearly 4-month project.
The bugs kept coming: The UX of the initial integration was not great and not something we even felt proud putting our name on. Several issues and bugs continued to follow the initial launch. Reflecting on this - a majority of issues were largely due to the fact we had a pretty backend and complex UX problems felt quite a lot out of the scope of our natural expertise.
What you see is what you (don't) get: The customer also wanted specific changes made to the Rye experience, and that led to some negotiation and back and forth. This also added time to what felt like a very time-constrained project.
😱: In part, this period was made worse due to us taking on more customers and feeling overwhelmed by the slew of bugs. We bit off more than we could handle.
Of course, a technical project of any sufficiently large scope only executes with hurdles. And boy, did we have our share.
Scope creep abundance
The biggest challenge in any project is dealing with scope creep abundance. The main issue when providing resources to end customers is the expansion of scope. This was the case for us, and it was especially worse because our team mostly focused on backend development.
We encountered major issues with an upstream vendor that were beyond our control. Instead of limiting the scope of the feature, we decided to implement workarounds for the issue. This significantly increased the scope of our initial integration. To put it into perspective, our 6-week project turned into a nearly 4-month project.
The bugs kept coming: The UX of the initial integration was not great and not something we even felt proud putting our name on. Several issues and bugs continued to follow the initial launch. Reflecting on this - a majority of issues were largely due to the fact we had a pretty backend and complex UX problems felt quite a lot out of the scope of our natural expertise.
What you see is what you (don't) get: The customer also wanted specific changes made to the Rye experience, and that led to some negotiation and back and forth. This also added time to what felt like a very time-constrained project.
😱: In part, this period was made worse due to us taking on more customers and feeling overwhelmed by the slew of bugs. We bit off more than we could handle.
Of course, a technical project of any sufficiently large scope only executes with hurdles. And boy, did we have our share.
Scope creep abundance
The biggest challenge in any project is dealing with scope creep abundance. The main issue when providing resources to end customers is the expansion of scope. This was the case for us, and it was especially worse because our team mostly focused on backend development.
We encountered major issues with an upstream vendor that were beyond our control. Instead of limiting the scope of the feature, we decided to implement workarounds for the issue. This significantly increased the scope of our initial integration. To put it into perspective, our 6-week project turned into a nearly 4-month project.
The bugs kept coming: The UX of the initial integration was not great and not something we even felt proud putting our name on. Several issues and bugs continued to follow the initial launch. Reflecting on this - a majority of issues were largely due to the fact we had a pretty backend and complex UX problems felt quite a lot out of the scope of our natural expertise.
What you see is what you (don't) get: The customer also wanted specific changes made to the Rye experience, and that led to some negotiation and back and forth. This also added time to what felt like a very time-constrained project.
😱: In part, this period was made worse due to us taking on more customers and feeling overwhelmed by the slew of bugs. We bit off more than we could handle.
Liberation
At one point during this project, we realized that the integration would take longer, and we were not satisfied with the state of things. We halted all sales and decided to concentrate our entire team on the single integration at hand. This decision felt liberating emotionally, as it relieved us from the artificial pressure we had put on ourselves to rapidly expand our customer base. Instead, it allowed us to refocus on building a great product that our customers wanted to use.
A lot of the learnings were gained by doing retros after the integration finished within Rye, with our internal team. This is something we try to do after finishing large projects or every few quarters.
At one point during this project, we realized that the integration would take longer, and we were not satisfied with the state of things. We halted all sales and decided to concentrate our entire team on the single integration at hand. This decision felt liberating emotionally, as it relieved us from the artificial pressure we had put on ourselves to rapidly expand our customer base. Instead, it allowed us to refocus on building a great product that our customers wanted to use.
A lot of the learnings were gained by doing retros after the integration finished within Rye, with our internal team. This is something we try to do after finishing large projects or every few quarters.
At one point during this project, we realized that the integration would take longer, and we were not satisfied with the state of things. We halted all sales and decided to concentrate our entire team on the single integration at hand. This decision felt liberating emotionally, as it relieved us from the artificial pressure we had put on ourselves to rapidly expand our customer base. Instead, it allowed us to refocus on building a great product that our customers wanted to use.
A lot of the learnings were gained by doing retros after the integration finished within Rye, with our internal team. This is something we try to do after finishing large projects or every few quarters.
All's Well That Ends Well
In the end, the integration worked. We started seeing a steady flow of orders from the customer and kept our check-ins for long-standing bugs. We also handed over ownership of the codebase to the customer, wrote ample documentation, and coordinated on ops issues that occurred.
Reflecting on the experience, building B2B companies can be extremely rewarding, and this is especially true in the earlier days because of the love and care you can pour into early customers when you’re not worried about scale. Every single team member can recount the hardships, pressure, and stress of the project. But at the same time, it's honestly wonderful to build a deep relationship with our customers. We learned a lot through this experience, and it certainly allowed our product to mature and move in the direction we envisioned. These types of early integrations are the ones that unlock your ability to scale to more customers. Take your time, commit, and build well.
In the end, the integration worked. We started seeing a steady flow of orders from the customer and kept our check-ins for long-standing bugs. We also handed over ownership of the codebase to the customer, wrote ample documentation, and coordinated on ops issues that occurred.
Reflecting on the experience, building B2B companies can be extremely rewarding, and this is especially true in the earlier days because of the love and care you can pour into early customers when you’re not worried about scale. Every single team member can recount the hardships, pressure, and stress of the project. But at the same time, it's honestly wonderful to build a deep relationship with our customers. We learned a lot through this experience, and it certainly allowed our product to mature and move in the direction we envisioned. These types of early integrations are the ones that unlock your ability to scale to more customers. Take your time, commit, and build well.
In the end, the integration worked. We started seeing a steady flow of orders from the customer and kept our check-ins for long-standing bugs. We also handed over ownership of the codebase to the customer, wrote ample documentation, and coordinated on ops issues that occurred.
Reflecting on the experience, building B2B companies can be extremely rewarding, and this is especially true in the earlier days because of the love and care you can pour into early customers when you’re not worried about scale. Every single team member can recount the hardships, pressure, and stress of the project. But at the same time, it's honestly wonderful to build a deep relationship with our customers. We learned a lot through this experience, and it certainly allowed our product to mature and move in the direction we envisioned. These types of early integrations are the ones that unlock your ability to scale to more customers. Take your time, commit, and build well.
Related articles
Related articles
Accelerate your commerce operations
Accelerate your commerce operations
Accelerate your commerce operations
Product
Resources
Solutions
Product
Resources
Solutions
Product
Resources
Solutions