When we started working on Sopunto, the technical side was not our main problem. We knew how to build landing pages, corporate websites, automations, integrations, and custom applications. We also had experience designing interfaces, gathering requirements, and turning manual processes into systems people could actually use. The difficult part was answering a much more basic question: what kind of business were we building with all those capabilities?Having many things to offer may seem like an advantage, but it can quickly become a very effective way of having no focus at all. A company can introduce itself by saying that it builds websites and applications, works with design and artificial intelligence, creates automations, offers consulting, and does practically anything else that sounds digital. The problem appears when a potential client tries to understand why they should hire that company, what kind of problem it is especially good at solving, or what makes it different from the other twenty companies saying exactly the same thing.Our first definition of Sopunto looked more like a list of services than a business model. We could explain what we were capable of building, but we had not yet defined clearly enough who we wanted to build it for, what outcome those people expected, or how we could deliver that value sustainably. We used the Business Model Canvas to organize those questions.
What the Business Model Canvas is and what it is used for
The Business Model Canvas is a visual tool for describing, designing, and challenging a business model. It organizes a company into nine interconnected building blocks: customer segments, value propositions, channels, customer relationships, revenue streams, key resources, key activities, key partners, and cost structure. Its purpose is not simply to summarize a business on one page, but to make it possible to examine its different parts as a system.The relationship between these blocks matters because a business model does not work as a collection of independent answers. A revenue stream has to come from a customer segment willing to pay for a specific value proposition. Delivering that proposition requires activities and resources, and all that work generates costs.This may sound obvious when explained that way, but it is very easy to lose sight of it when we are excited about an idea. We can imagine a technically interesting application without knowing how it will attract users. We can define a monthly subscription without confirming that the service delivers value every month. We can also decide that our customer will be “any SME” and later discover that this group includes businesses with completely different problems, budgets, and purchasing processes.The Canvas does not resolve those contradictions for us. What it does is make them visible, which is already considerably better than having our ideas scattered across conversations, documents, WhatsApp messages, and a spreadsheet called business-model-final-for-real-this-time-v3.xlsx.
Sopunto’s first problem: we could do too many things
Our starting point was defined by the team’s capabilities. We knew how to create websites, internal systems, forms, administrative dashboards, integrations, and automations. From a technical perspective, that made sense. From the customer’s perspective, however, an explanation was still missing.A business does not usually begin the day thinking it needs an API integration. What it knows is that someone is copying information from one platform to another several times a week and that, sooner or later, the process will result in incorrect data. A consultant does not necessarily dream of having a landing page either. What they want is to explain their service more clearly, receive inquiries from interested people, and stop coordinating every meeting by exchanging eight messages to find an available time.That difference was one of our first important lessons. We thought in terms of solutions because we came from the development world, while the customer thought in terms of problems, even if they did not always describe them that way. They might ask for a website when what they really needed was to build trust. They might ask for an application when their immediate need was to organize a process. They might ask for an automation even though they had not yet decided which parts of the process should remain and which ones should be removed.That is why the Canvas forced us to stop describing Sopunto exclusively through what we could build. Features are important, but they do not constitute a value proposition on their own. Saying that a platform includes users, notifications, and an administrative dashboard explains how it works. Explaining that it reduces the time spent coordinating bookings makes it clear why someone might want to use it.
Our customer could not simply be “an SME”
In one of the first versions of the Canvas, our segments included entrepreneurs, independent professionals, small businesses, restaurants, clinics, stores, and businesses that worked through Excel or WhatsApp. It was broad enough for almost any company in Chile to feel included, which also meant that it did not help us make many decisions.A clinic that needs to manage appointments and patients has a different problem from an industrial company receiving quotation requests. An independent professional may hire a landing page to present a specific service, while an organization with several departments will probably need a much broader content architecture. Although all of them could be described as businesses in need of digital support, they do not evaluate solutions in the same way or expect the same type of relationship.We therefore began looking at segments not only according to industry or size, but also according to the situation those businesses were facing. We were interested in companies that already had a real operation, but whose digital experience did not reflect the quality of that operation. Companies that provided a good service, even though their website was unable to explain it. Professionals who depended on referrals, emails, and messages to organize activities that could be handled much more simply.Another group also emerged: companies that had grown using manual tools until those tools began to show their limitations. Excel, email, and WhatsApp can support a significant part of an operation, and there is no reason to replace them simply because newer technologies exist. The problem begins when information is duplicated, processes depend on one person’s memory, nobody knows which version of a file is the latest, or a simple task requires checking four different conversations.This helped us define a more specific segment: growing businesses with an identifiable digital need for which we can propose a proportionate solution. It does not mean that all of them need custom software. In fact, an important part of our work is recognizing when they do not.
The value proposition had to explain our judgment
One of the first ways we described Sopunto was as a link between design and software development. The idea represented something we had seen many times: visually attractive websites that did not help the business achieve anything, and technically functional systems that appeared to have been designed without considering the person who would actually use them.We did not want to choose between a beautiful solution and a useful one. Our intention was to combine design, technology, and business understanding to create something that could be used, maintained, and serve a specific purpose. However, that explanation was still too focused on how we worked and not necessarily on what the customer received.During this process, principles emerged that remain important to us, such as selling solutions instead of smoke and guiding the customer toward an option that is better thought out as a product. The challenge was turning those internal ideas into a proposition that could be understood by someone who does not spend their life talking about user experience, architecture, or automation.The definition began to take shape when we stopped presenting each service as an isolated product. Sopunto did not have to be merely a company that sold websites or software. It could be a company that understood a problem and recommended an appropriate digital solution for it, even when that solution was smaller than the one initially imagined.This changes the sales conversation considerably. If someone needs to begin receiving bookings, they may be able to solve the first stage with a landing page, a connected calendar, and automated emails. It would make little sense to build a platform with users, calendars, and notifications from scratch before confirming that real demand exists. On the other hand, if a company needs different permissions, traceability, statuses, documents, and integrations, then we are probably dealing with a problem that requires custom software.Our value proposition, therefore, is not about always selling the largest project. It is about understanding which part of the business needs to improve and building something appropriate for that moment, that problem, and that investment capacity.
Channels had to form a journey, not merely a list of contact methods
In the channels block, we initially wrote down fairly obvious alternatives: website, email, WhatsApp, referrals, and meetings. All of them could be used to communicate with a customer, but the Canvas led us to ask a different question: how does someone go from not knowing Sopunto to considering that we might be able to help?That journey usually begins before the contact form. A company notices that something is not working properly, even if it does not yet know how to describe the problem. It then finds a recommendation, an article, a message, or a case similar to its own. Only after that does it review our services, try to understand how we work, and decide whether starting a conversation is worthwhile.The blog is part of that process. We do not expect someone to finish reading an article about the Canvas and immediately hire us to build an administrative system. Its purpose is to show how we analyze a problem, what questions we ask, and why we do not begin by offering a technology before understanding the situation.This approach also changes the type of content that makes sense for us to publish. Instead of writing generic articles about technology trends, we can use real experiences to explain decisions that other businesses also face: when a landing page makes sense, what ongoing support includes, how to identify a process that can be automated, or why an application is not always the best starting point.
The customer relationship had to be close, but also clear
Another relevant block was customer relationships. From the beginning, we knew that we did not want to operate merely as executors of a requirements list. The customer understands their business much better than we do, but that does not mean the first solution they imagine is necessarily the most appropriate.Part of our work is asking why they need something, who will use it, what currently happens, and what outcome they expect to achieve. Those questions are not meant to complicate the project, but to prevent us from building the wrong solution correctly.A consultative relationship also has limits. Supporting a customer should not mean making them permanently dependent on us. They should know what was built, which accounts and permissions they own, which external services they use, how much those services cost, and what would happen if they decided to work with another provider in the future. Closeness without transparency can easily become dependency, and that is not the kind of relationship we want to build.That is why support must coexist with clear scopes, understandable deliverables, and commercial terms that explain what is included. Trust is not built by promising that everything will be easy, but by allowing every party to understand what is being done and why.
Revenue, costs, and the less romantic side of the model
When people think about starting a software company, it is much more enjoyable to talk about products, design, and innovation than about unpaid meetings, licenses, support, taxes, and hours spent fixing something that initially looked small. The financial side of the Canvas exists precisely to remind us that a good idea also needs to be sustainable.The most obvious source of revenue for Sopunto was project-based development. The customer hires us for an agreed scope, a payment structure is defined, and a solution is built. However, real ongoing needs may appear after delivery: infrastructure, domains, support, corrections, new features, monitoring, or improvements.The important point was not to group all of those things under an ambiguous term such as “maintenance.” A recurring payment should correspond to a recurring service. If hosting, support, or technical administration is provided, it should be explained. If there is no ongoing activity, charging monthly simply because subscription models are fashionable does not improve the business; it only makes the fee harder to justify.The Canvas also made us consider less visible costs. The price of a project does not automatically become profit. Before delivering a solution, there was research, meetings, design, development, and testing. Afterwards, there may be documentation, deployment, support, and coordination. On top of that, there are tools, infrastructure, administration, and the commercial time required to secure the next project.This review matters because an apparently small feature can hide considerable complexity. Adding a button may be simple. Making that button validate information, query an external provider, record the operation, handle errors, and send the correct notification is another matter entirely.
Key resources and activities were not limited to code
In our Canvas, key resources included technical knowledge, design, tools, infrastructure, and reusable components. Over time, we realized that we also had to consider less obvious resources, such as the judgment required to define scopes, the ability to understand processes, documentation, the brand, and the team’s actual availability.In a service company, time is an especially delicate resource. We may have the technical ability to accept several projects and still lack the operational capacity to execute them with the level of care we promise. A full calendar is not always evidence of a healthy business; sometimes it simply means that nobody calculated how much work was behind each delivery.Something similar happened with key activities. At first, it was tempting to summarize them as designing and developing software. In practice, a project begins well before the code and ends long after it. We have to research, understand the problem, define users, establish the scope, design, develop, test, deploy, document, and support the launch.Sopunto also needs activities that are not connected to a specific project: finding opportunities, preparing proposals, following up, recording lessons, and improving the offer. If all available capacity is dedicated exclusively to production, sooner or later there will no longer be a commercial pipeline to sustain the work.
Key partners are also part of the solution
No digital solution exists entirely in isolation. Even a relatively simple website may depend on providers for domains, hosting, email, analytics, forms, or scheduling. A more complex system may also use storage, payments, authentication, notifications, and cloud infrastructure.These providers make it possible to build better solutions more quickly, but they also introduce dependencies, conditions, and costs. That is why the key partners block cannot be completed by simply writing “technology providers.” We need to understand the role each one plays, how much it costs, and what would happen if it changed its prices or discontinued the service.This analysis also helps us communicate proposals more clearly. If a solution depends on an external scheduling platform or payment gateway, the customer needs to know. The cost of developing an integration does not eliminate the fees charged by the integrated service. It is better to explain that at the beginning than to discover it later, once the platform is ready and someone asks why a new subscription has appeared on the company card.## What we actually learned from the CanvasThe main lesson was not how to complete nine blocks correctly. It was understanding that the model needed a complete internal logic. Customers, the proposition, channels, activities, and revenue had to describe the same business, not five different versions of what we wanted Sopunto to be.We also learned that a list of services does not replace a value proposition. Saying that we build landing pages, automations, and software helps explain our capabilities, but it does not explain the outcome we are trying to produce. The proposition appears when we connect those capabilities to a specific problem.Another lesson was that the Canvas contains hypotheses, not certainties. Writing that our ideal customer is a growing business does not automatically make every growing business a good customer. That idea must be tested through conversations, quotations, projects, rejections, and results. Some segments will show a better fit than others, certain services will be more profitable, and some propositions that seemed obvious will eventually be discarded.That is why a Canvas should not be completed once and then archived as proof that strategic planning took place. It makes sense to revisit it whenever new lessons emerge. If the model remains exactly the same after speaking with customers and delivering projects, we are probably not paying enough attention to what is happening.
How to use a Business Model Canvas effectively
The best way to use the Canvas is to write down specific situations instead of overly broad concepts. “Companies that want to go digital” can include practically any organization. “Consulting firms that coordinate meetings manually and lose time finding available slots” describes a situation that we can observe, investigate, and solve.It is also important to separate problems from solutions. “Online scheduling” is not a problem; it is one possible tool. The problem may be that a professional spends several hours each week coordinating meetings. Once we understand that, we can evaluate whether the correct response is a scheduling tool, a form, an automation, or a simpler change to the process.After completing the blocks, we need to look for contradictions. Can the segment afford to pay? Does the channel actually reach those people? Does the revenue stream cover the activities and costs? Does the proposition depend on resources we do not yet have? Is there a provider on which too much of the service depends?Finally, the riskiest hypotheses should become small tests. Before developing an entire platform, we can validate a proposition with a landing page. Before automating a complete operation, we can test part of the workflow. Before assuming that a company will pay a monthly support fee, we need to understand which ongoing service it truly considers valuable.
A model for deciding what is worth building
The Business Model Canvas did not give us a definitive answer about Sopunto, but it helped us organize the conversation. It forced us to move from “these are all the things we can do” toward much more useful questions: which problems we want to solve, which businesses we can serve well, how we will reach them, and what we need to sustain the work.It also left us with an idea that seems obvious today, although it was not always so clear at the beginning: technology should emerge as a consequence of the problem and the business model. It makes no sense to begin with an application if we still do not know who needs it, what value they will receive, or how it will be sustained after launch.Sometimes the solution will be a simple website. In other cases, it will be an automation or an integration. There will also be problems that justify developing a complete platform. The work is not about always using the most complex technology, but about recognizing what is sufficient to produce a real change.That, ultimately, is what the Canvas contributed to Sopunto. It did not automatically turn an idea into a business, but it gave us a structure for discussing it, identifying gaps, and making decisions with slightly more judgment than our initial enthusiasm alone could provide. When you are starting a project, having a tool that forces you to think before you build is already a significant advantage.