We love writing code, but we try to avoid having to. Our vocation is to create products that solve problems and how to create them must always be aligned with the problem we want to solve and the available resources. Writing code should be the means, but never an end in itself.

As technical people it is easy to be tempted to customize each solution, write a lot of code and create true "tailored suits". However, technology is only one of the pieces that make up a product, not the only one. Design is just as important and we talked about it in a previous article. And today we present the third and final piece: the business.

Do you know what the core of your business is?

Understanding the core of our business will allow us to identify the tools that we will use to build the product and prioritize our efforts. Sometimes it will be a SaaS that perfectly solves one of the parts of the product, in others it will be existing platforms or frameworks that will allow us to speed up its creation and, indeed, there will be times where we will have to write code.

It is almost as important to understand what the core of your business is, as it is to understand everything that is not. Is processing payments the core of my business? Is the infrastructure the core of my business? Is sending emails the core of my business? The answer to these questions will help you order and prioritize efforts in each area of your product.

Be careful, that it is not the core of the business does not mean that it is not important. It simply means that it is not differential, only necessary. If you have an online store, being able to accept payments is not differential, it is necessary. Even the platform of your store is not differential but necessary to be able to sell. On the other hand, the product, distribution and marketing are unique and differential factors for the success of your store.

Many times this process can be simplified into a single question: Is this going to determine the success of my business? For example: Will developing a custom solution for sending emails versus using an existing service like SendGrid determine the success of my online store? If the answer is "no" we may be misaligning resources and efforts at the core of the business.

Some of the no-code tools we use at Reboot

Cases that we find in Reboot

1. Lead capture landing

A common project that we work with from the Studio is that of a startup or company that needs a landing to advertise its product or service and to be able to capture leads from interested people.

In these cases our priorities are usually:

  1. Design and narrative
  2. Empower the team
  3. Performance

Each of these objectives determines what technologies and tools we will use to build the landing.

  1. The objective here is clearly to sell the product or service, so we have to be able to create a landing with a design and narrative that differentiates, persuades, generates trust and interest. Therefore, we need full freedom to execute our design, avoiding template systems or drag-and-drop editors of doubtful quality.
  2. Second, we need a solution that does not limit but empowers the promoter team of the project. The product and discourse will surely evolve over time and we need to provide the autonomy to be able to translate these changes without creating a dependency on the studio, agency or technical team. This may be seen as a bad business decision as a product study, but it is completely aligned with our values.
  3. Finally, we need a landing that simply works under any circumstance, without transferring to the team the typical problems of infrastructure, servers, availability, among others.

So ... what would be our proposal for this case?

  • Webflow would be our entry solution to build the landing. It offers absolute freedom for the execution of the design, allows to make changes in a very intuitive way thanks to its editor and abstracts the team from the mentioned problems of performance, hosting and availability. As an alternative, we have also sometimes recommended developing a custom frontend with Next.js and integrating a HeadlessCMS for copy and content management.
  • Typeform for capturing leads when you want to create complex, personalized forms with a good user experience. It is also possible to use the form tool that integrates the Webflow for these cases.
Landing built in the Studio using Webflow and Typeform

2. Ecommerce

The technology to start an online store today is already a "commodity". It is not even necessary to have technical knowledge to do it, although many still try to continue reinventing the wheel.

The challenge of the project is to understand well the particularities of the product to be sold and to offer the best option based on this.

  1. Shopify is usually our preferred ecommerce solution for the vast majority of cases. Tested and verified by millions of brands that every day sell hundreds of millions of dollars on the platform, with thousands of integrations available at a single click from the store and, again, completely abstracting the hosting and performance layer and giving us a cloud solution that "it just works". Sometimes we can also explore other platforms such as BigCommerce.
  2. When design, customization and branding have a very important weight we recommend creating a storefront. A storefront is an independent website that integrates with your ecommerce in order to display products in a unique and differential way. For us, it offers the best of both worlds: the robustness and reliability of an ecommerce platform like Shopify with the freedom and flexibility to create a unique web experience.

It is not about reinventing the wheel, the technology to create and launch e-commerce is already here, so our job should be to understand the business and its peculiarities, and offer the best solution for it.

The problem, again, is that this often works against the business as a studio / agency / service provider. Sometimes reinventing the wheel is the only way to justify an exaggerated budget and number of hours. Of course, this is not the way we do business at Studio and it never will be.

Ecommerce built in the Studio using Snipcart and Prismic

3. Infrastructure without DevOps

Finally, infrastructure is usually one of the main headaches of any project. Ensuring that our product is available and accessible at any time for users is essential, but we are not specialists in Infrastructure. How do we do it then?

In our case we rely on PaaS (Platform as a Service) such as Heroku, Render or Vercel for the deployment of all the projects that we develop in the Studio. These are some of the reasons:

  1. Predictability. You know how much you are going to pay at the end of the month, something essential for any business.
  2. Scalability. If your product requires it, these platforms can scale the resources according to your specific needs.
  3. Simplicity. Being able to have different development environments easily, being able to make quick deployments by pushing the project repository without having to connect to an FTP.
  4. Intuitive. It is very easy to enter the panel of any of these services and understand the status of your product: if it is deployed, perform a rollback to a previous version if something has gone wrong, etc.
  5. They are not lock-in. When your product matures and requires a more complex infrastructure, you can stop using these services and switch to your own solution in any other service.
We use Vercel and Render to deploy our own website and Blog

Conclusions

In short, we are dedicated to building products that are framed in specific technology, design and business needs. You can't create good products if you don't consider any of the above. It must be understood from the honesty to propose the best solution for the client's challenge, although sometimes this is not the best decision for your treasury.

Product work never ends, it is a constant process of learning, iteration and experimentation. The tools and technologies with which the product is built can also evolve. They must evolve. And our process contemplates offering the best solution for each stage, avoiding premature oversizing, but being prepared to scale when necessary.