Maciej Mikołajek.Product engineer & founder.

The products were different. The domain was not.

Both systems needed to understand the same durable objects.

A lesson belonged to a student, a teacher and a subject. Materials and whiteboard context had to survive beyond a single meeting. Completed lessons affected settlements. The organization version added coordination, but it did not replace the teaching relationship with a different domain.

We had treated a difference in scale and responsibility as a difference in product identity.

That distinction matters. Two sales motions do not automatically require two data models. Two interfaces do not automatically justify two implementations of the same rules.

The cost became visible as we worked with both independent tutors and an organization pilot covering roughly 20 teachers and 200 students. A change to lessons, students or settlements could no longer be considered in one place. We had to decide which behavior was shared, which version should receive it first and how the two systems would remain consistent.

For a larger organization, that duplication might have been absorbed by separate teams. We were three people. Every hour spent maintaining the boundary was an hour not spent improving the product.

The wrong response would have been a permanent integration layer.

One option was to keep both systems and connect them more carefully. That would have preserved the work already completed and reduced the immediate disruption.

It would also have made the accidental boundary permanent.

We would still have had two interpretations of a student, a lesson and a settlement. Shared features would still need coordination. Moving a tutor into an organization would still require us to explain which data belonged where. Integration would hide the duplication without removing it.

The other option was to treat both products as modes of one workspace.

In that model, a solo tutor uses a one-member workspace. A school uses the same foundation with more members, roles and assignments. Students, lessons, materials and history remain part of the same domain. Organization capabilities extend that model through permissions, reporting and coordination rather than introducing a parallel product.

We chose the shared foundation.

Consolidation moved the complexity. It did not erase it.

One system is easier to describe, but not automatically easier to build.

Permissions now affect almost every meaningful operation. Ownership has to be explicit. A feature that is obvious for one tutor may require several access rules inside a school. The interface must reveal organization controls when they are useful without making the solo product feel like enterprise software.

There is also roadmap pressure. Organization customers naturally ask for administration, reporting and financial workflows. Independent tutors care more about the speed and quality of the teaching loop. A shared foundation cannot become an excuse to make every user carry every piece of complexity.

The design principle became progressive exposure: keep the domain shared, but expose coordination only when the workspace needs it.

This is a more demanding foundation than two isolated happy paths. It is still the better use of a three-person team.

The leadership decision was not “use multitenancy.”

Multitenancy is an implementation choice. The harder decision was admitting that a boundary we had already invested in was no longer serving the product.

Continuing would have been easier in the short term. Each system already worked on its own terms. Consolidation required us to revisit assumptions, accept migration work and move complexity into permissions and product design.

But sunk effort is not a reason to preserve the wrong boundary.

The useful question was not which architecture looked cleaner. It was which model allowed three people to keep learning from two customer segments without slowly becoming two separate companies.

The answer was one domain, one foundation and two deliberately different ways of exposing it.

We separated the stable system from the changing presentation.

The core backend acted as a multitenant control plane. It owned customers, campaigns, devices, assignments, sessions and leads.

Campaigns were independent React applications. Each could have its own content, interface and release cycle while implementing the same event and lead contracts. An iOS kiosk shell handled the physical device and loaded the campaign assigned to it. The backend could support more campaigns and connected tablets without embedding customer-specific presentation logic in the core system.

That architecture gave us the flexibility we wanted. Campaigns could change without a native application release. Devices could be reassigned centrally. Session data remained comparable even when the visible experiences differed.

The product reached its first paying customer within four months. During rollout it recorded more than 1,700 sessions and captured 76 leads.

The system worked in the environment it had been designed for.

A new customer still meant much more than a new tenant.

Software scalability is easy to see in a diagram. Business scalability is visible in the work required after the contract is signed.

Every SalesPad deployment still involved some combination of hardware sourcing, delivery, installation, connectivity checks, on-site setup, campaign preparation, dealership coordination and field support. A tablet placed in a public environment had to remain charged, connected, correctly configured and physically presentable. A campaign had to match the vehicle, location and commercial offer.

None of this was a bug in the control plane. It was part of delivering the product.

We had designed the software so that campaign variation did not corrupt the backend. We had not removed the operational work surrounding every campaign and device.

The distinction became increasingly important. Server load did not grow in a worrying way. Operational attention did. Adding customers was technically cheap and organizationally expensive.

The unit of scale was a deployment, not a request.

Engineering teams often discuss scale in terms of requests, users, rows or events. Those measures matter, but they were not the binding constraint here.

For SalesPad, the more useful unit was the customer deployment.

How much preparation did it require? How many physical steps had to happen in the correct order? How much customer-specific content was involved? How often did someone need to visit or remotely diagnose a device? How long did a dealership take to make a buying decision?

A backend can absorb ten times more traffic while the organization remains unable to deploy ten times more customers.

Once we evaluated the whole delivery system rather than only the software, the economics looked different. The business was scaling through operations alongside software, not through software alone.

Clean architecture could not change the surrounding economics.

We could have continued automating parts of the deployment process. Better device management, reusable campaign templates and stricter rollout procedures would all have reduced friction.

They would not have removed the hardware, physical environment or dealer-by-dealer sales cycle.

At some point, improving the system further would have meant using engineering to optimize around a business constraint rather than removing it.

We closed SalesPad because the remaining path required more operational growth than we wanted to build around. That decision did not mean the software had failed. It meant the software had succeeded at its own layer and exposed the constraint outside it.

The lesson was not to avoid products connected to the physical world. It was to model their non-software path with the same discipline as their backend.

Before calling a system scalable, map what has to happen for the next customer to receive value. If that path still requires proportional human work, a scalable architecture may be supporting an unscalable delivery model.

I had mistaken an understandable problem for my problem to solve.

I was not a heavy email user. I was building for an imagined person whose daily behavior I did not understand closely enough.

That distance was easy to hide because the product was technically interesting. There was always a legitimate system problem to solve: another synchronization edge case, a provider difference, an OAuth restriction, a Gmail API limit or an architectural improvement that made the application cleaner.

Beta feedback created motion as well. A user would suggest a change, I would implement it and the product would appear to be progressing. But responding to comments is not the same as observing a durable habit.

I spent months reducing technical uncertainty while the demand uncertainty remained largely intact.

The failure was not that nobody liked Blinkfeed. The failure was treating interest, feature requests and even a small number of payments as sufficient evidence that the product belonged in somebody's daily workflow.

SalesPad moved validation closer to behavior.

SalesPad started with an observable situation rather than a general frustration. Vehicles were being displayed in shopping centres and other locations without a measurable interaction layer. A paper specification stand could present information, but it could not show what visitors explored or connect that behavior to a lead.

The validation loop was more concrete. We could place the product in the real environment, see whether people interacted with it and measure what happened before a contact request.

Within four months, SalesPad reached its first paying customer. During rollout it recorded more than 1,700 sessions and captured 76 leads.

That was much stronger evidence than positive interviews. People used the product in context. A customer paid. The system produced the behavior it had been designed to measure.

It also revealed another layer of validation that I had previously underestimated: a product can create value and still sit inside a delivery model that is difficult to scale. Hardware, installation, campaign preparation, field work and long dealership sales cycles remained part of every rollout.

SalesPad validated the product more effectively than Blinkfeed. It did not validate the surrounding business as the type of company we wanted to scale.

Pewniutko changed the order again.

With pewniutko.pl, we moved closer to a recurring workflow and exposed the product to real use earlier.

The problem is not simply that tutors lack a feature. Their work is fragmented across calendars, messaging tools, whiteboards, files, homework and spreadsheets. The useful question is whether bringing that context together removes enough recurring friction to become part of how lessons are run.

In June 2026, pewniutko.pl had roughly 180 registered users. At that time, a separate organization pilot covered approximately 20 teachers and 200 students. We can observe not only acquisition, but registration, trial behavior, lesson workflows and the different needs of solo and multi-member workspaces.

That evidence has already changed the product. The solo and organization versions initially existed as separate systems. Real use made the duplication and shared domain visible, so we consolidated them around one multitenant foundation.

Validation is now expected to change architecture, scope and positioning. It is not a stage completed before implementation.

The standard of evidence should rise with the cost of the next decision.

I now separate several signals that I previously allowed to blur together:

• A person understanding the problem is not evidence that they experience it frequently.
• A person requesting a feature is not evidence that the feature will change their behavior.
• Registration is not activation.
• Initial use is not retention.
• A paying customer validates value, but not necessarily a repeatable sales or delivery model.
• A technically successful product is not automatically the right business to continue.

The point is not to demand perfect certainty before building. Early products need judgment precisely because the evidence is incomplete.

The point is to define what the next piece of evidence must prove before investing in the next layer of complexity.

Blinkfeed taught me that technical progress can conceal weak demand. SalesPad taught me that paid usage can coexist with poor delivery economics. pewniutko.pl is teaching us to use real workflows to reshape the product while it is still small enough to change.

Positive feedback is useful. It should start the investigation, not conclude it.

The narrow loop made the first product possible.

The visitor needed to understand the offer, explore the vehicle and have a clear way to express interest. The dealer needed the resulting lead and enough behavioral context to understand what preceded it.

That defined the first system:

• a public kiosk experience beside the vehicle;
• campaign content tailored to the offer;
• lead capture with the required consent;
• session and interaction tracking;
• a control plane for customers, campaigns and devices;
• a handoff into the dealership's existing workflow.

Everything else was secondary until that loop worked in a real location.

The architecture supported variation without making every customer a fork. Campaigns shipped as independent React applications. A central backend owned tenants, campaign assignments, device routing, sessions and leads. An iOS shell handled the tablet and loaded the experience assigned to it.

The technical boundaries mattered, but they were not what produced the first customer.

Customer conversations and implementation happened together.

In an early-stage B2B product, the founder does not finish discovery and then hand a specification to engineering. Each conversation changes what needs to be built, demonstrated or removed.

Dealership discussions forced us to translate a general analytics idea into an operational product. Where would the device stand? Who would provide the campaign content? What happened to a lead after submission? Which interactions were meaningful rather than merely easy to record? What did the dealership need to see before agreeing to a pilot?

The answers affected the interface, event model, deployment process and sales narrative at the same time.

Field testing exposed a different class of requirement. The product had to work on an unattended device in a public environment. A web application that behaved correctly on a developer's laptop was not enough. Device configuration, navigation, connectivity and recovery were part of the customer experience even though the visitor never saw them directly.

The fastest path was not to postpone those constraints. It was to encounter them while the product was still small.

The first contract changed the quality of the feedback.

A prospect can be enthusiastic without changing anything about their operation. A paying customer has made a different commitment.

The first paid rollout forced the complete system to work together: campaign, device, location, lead capture, analytics and dealership handoff. It also created evidence that could not be produced in a demo.

Across the rollout, SalesPad recorded more than 1,700 sessions and captured 76 leads. We could see how visitors moved through the experience and which actions preceded contact requests.

Those numbers did not prove that every dealership would buy. They proved that the product could operate in the intended environment, attract real interaction and generate measurable commercial outcomes.

That was the correct milestone for the first four months.

Speed came from owning the whole path, not only writing code quickly.

The product reached a paying customer because discovery, product decisions, engineering, deployment and sales were treated as one delivery problem.

If any one of those areas had been optimized independently, the pilot would have taken longer. A more complete platform without a customer would not have helped. A signed pilot without reliable device behavior would not have helped. More events without a clear dealer workflow would not have helped.

Founder-led delivery meant moving between these layers and deciding what was sufficient for the next real commitment.

It also meant accepting that some work which looked operational was product work. Preparing the campaign, configuring the tablet and checking the physical setup were necessary to learn whether the software created value where it was supposed to.

What the first customer did not prove.

Reaching revenue quickly is a useful signal, not the end of validation.

SalesPad proved that dealerships could pay, visitors would interact and the product could generate leads. It did not prove that hardware sourcing, installation, campaign preparation, field support and long dealership decision cycles could scale with the economics we wanted.

That distinction later became the reason to close the product.

The four-month result still matters. It showed that a small team could move from observation to a deployed, paid system without separating product thinking from technical execution.

The broader lesson is simple: for an early B2B product, define the smallest complete path to paid use. Then build every part of that path — including the inconvenient operational parts — before expanding the platform around it.

Do not rebuild a product whose main problem is weak demand.

Blinkfeed was an AI-native email client with a substantial technical core: Gmail and Outlook synchronization, OAuth, local persistence, thread summaries, semantic filtering, urgency detection and assisted replies.

It was easy to find reasons to improve the system. Email providers behaved differently. Background synchronization had edge cases. Beta users requested changes. The architecture could always be cleaner.

But the core problem was not that the implementation needed another iteration. I had built for a user whose daily email behavior I did not understand closely enough. Positive reactions and early payments did not become strong, repeated use.

Rebuilding onboarding or synchronization would have reduced technical friction around demand that was still too weak.

The correct decision was to stop.

That was not a judgment that the code had no value. It was a judgment that additional code was not the scarce input the product needed.

Merge systems when duplication reveals the wrong boundary.

pewniutko.pl initially had separate systems for independent tutors and education organizations.

The split helped us validate two customer contexts quickly. It also duplicated concepts that were fundamentally shared: students, teachers, lessons, materials, whiteboards, homework and settlements.

As a three-person team working with both solo users and an organization pilot, we could see the long-term cost. Every shared feature required another decision about ownership and consistency. Keeping the systems separate would eventually make the team behave like two smaller teams maintaining two related products.

This was not a demand problem. Both modes represented real workflows. It was a boundary problem.

The correct decision was to merge them around one multitenant workspace model. A solo tutor became a one-member workspace; an organization extended the same domain with roles, permissions, reporting and coordination.

The consolidation introduced migration and authorization work, but that work removed structural duplication rather than polishing around it.

Shut down a working product when software is not the binding constraint.

SalesPad reached a paying customer within four months. It operated in real dealerships and public locations, recorded more than 1,700 sessions and captured 76 leads.

Its software architecture was not blocking growth. A central control plane coordinated independently deployed campaigns and iOS kiosk devices. More campaigns and devices did not require us to fork the backend.

The surrounding delivery model was the constraint.

Each rollout still involved hardware, installation, connectivity, campaign work, field support, dealership coordination and a long B2B decision cycle. More internal software could reduce portions of that work, but it could not turn a physical deployment into a self-serve SaaS activation.

The product worked. Continuing it meant choosing to build an operationally heavy company around that product.

We chose not to.

Rebuilding is justified only when the system is the proven constraint.

These cases changed the order in which I evaluate major technical work.

Before rebuilding, I now ask:

1. Is the underlying behavior strong and repeated, or are we using engineering to search for demand?
2. Is complexity caused by a poor system boundary, or by two genuinely different businesses?
3. Is software limiting growth, or is the constraint in sales, delivery, operations or economics?
4. What evidence would become possible after the rebuild that is impossible today?
5. What will we stop doing to pay for the change?

The last question matters because architecture is also resource allocation. A rebuild consumes the same people who could be learning from customers, improving the active workflow or reducing another constraint.

Technical leadership is not the ability to argue for the cleanest future system. It is the ability to decide whether the organization should merge, rebuild or stop — and to make that decision before implementation momentum makes it feel inevitable.

Blinkfeed did not need another rebuild. SalesPad did not need a more scalable backend. pewniutko.pl did need a shared foundation.

The code was different in each case. The leadership question was the same: what is actually preventing the product from becoming more valuable?