Case study · Startup experience, lessons, and current approach
LB — What I built then, how I would approach the same project today
A real startup experience showing both the original work and how I would now connect business validation, technical planning, team coordination, and software development before committing significant resources.
LB is intentionally anonymized. Identifying details have been removed because the purpose of this case study is the work, the decisions, and the lessons—not the historical brand.
The original project
A software startup where product, technology, people, and operations had to move together.
LB was an Italian B2B/B2C software startup developed in the mid-2010s around the discovery of businesses and services connected to sustainability and specific consumer needs. The project involved more than two years of operational work, including the pre-incorporation phase.
The product was not only a directory. It combined vertical search, public business profiles, consumer and merchant accounts, reviews, commercial offers, e-commerce flows, QR-based redemption, administrative tools, SEO-oriented pages, and supporting operational processes.
What was built
A working product, not just an idea.
- Vertical search and structured business profiles
- Consumer, merchant, and administrative accounts
- Reviews and merchant replies
- Offers / coupon e-commerce flows and QR generation
- Administrative and operational tools, including automated invoicing
- SEO-oriented public pages and a national business catalog built through structured research
My role
Hands-on development with responsibility across product, people, vendors, and operations.
As founder and administrator, I worked directly on the software while also coordinating the activities needed to keep the project moving across multiple fronts.
Product and technical work
Prioritization, UX/UI, hands-on full-stack development, shared technical decisions, hosting and infrastructure responsibilities, and coordination between product changes and implementation.
People and operations
Selection and coordination of collaborators, weekly objectives, workload organization, and keeping parallel activities unblocked.
Vendors and commercial coordination
Management of an external development vendor, coordination of external services and design work, support to commercial activity, and alignment between software, data, and business needs.
External initiatives
Preparation and coordination of applications for startup programmes and funding opportunities, plus interaction with external stakeholders and advisors.
Outcome
Technical completion did not equal business validation.
The project reached a working published platform and produced encouraging B2B signals, including initial affiliations and inbound interest. B2C demand, however, was not validated strongly enough before the available time and funding became insufficient.
The key retrospective lesson is not that a different strategy would certainly have succeeded. It is that a technically functioning product can still depend on assumptions that have not been tested strongly enough, while changes in the operating model can materially affect cost, scalability, and the time available to validate the market.
How I would approach it today
The same problem, a more structured decision process.
Years later, LB is a concrete example of how my approach changed: reduce the highest-impact business uncertainties first, then turn what we learn into technical scope, estimates, priorities, and an executable development plan.
Before building — Test the assumptions that justify the investment
Instead of starting from an MVP feature list, I would first identify the critical assumptions that need enough support to justify the next investment.
Consumer behaviour
Does sustainability information materially influence real choices, not only stated preferences?
Trust and criteria alignment
Do users understand and consider the methodology credible, and is there a meaningful segment aligned with the criteria?
Differentiation
Does clearer, source-backed sustainability information solve a problem that generic search and booking channels do not solve well enough?
B2B value and willingness to pay
Which outcomes create value for businesses, and can that value support a paid model?
Data availability and scalability
Can useful profiles be built from available information without creating an unsustainable amount of manual work?
Economic sustainability
Are there plausible combinations of acquisition cost, price, customer retention, support, and operating cost that can produce a sustainable margin?
Validation rule: reduce uncertainty only as far as the next decision requires.
The most important assumptions are ranked by two questions: how damaging would it be if the assumption were false, and how little reliable information do we currently have about it?
For each assumption I would compare the strength of the information we can obtain with the cost and time required to obtain it, how reversible the next decision is, and how much that information could realistically change the decision. Cheap direct checks and financial models are worth doing early; expensive pre-market tests may be postponed when a small live product can produce stronger information more efficiently.
The aim is not to prove the business before development. It is to gather enough evidence to justify the next investment while keeping unresolved questions explicit.
Decision before development
Proceed, with conditions
The available evidence would not justify stopping the concept outright. The remaining high-impact uncertainties can be tested more effectively through a deliberately limited Validation Product than through further expensive pre-market analysis.
From validation to software
Build only the software needed to answer the next important questions.
The next step is not yet a full MVP. It is a limited Validation Product designed to collect stronger evidence from real use while keeping development investment deliberately small.
Live validation
Real businesses, real public data, search, sustainability profiles backed by verifiable sources, comparison, favourites, contact actions, business claiming, trial/plan selection, limited merchant self-service, and analytics. This part observes spontaneous user behaviour and early B2B adoption.
Controlled tests
Separate non-indexed experiments with synthetic data for questions the live market cannot isolate cleanly—for example price/sustainability trade-offs, alternative explanations of the sustainability result, or presentation variants. Test data stays separate from live analytics.
Measurement built in
Searches, filters, profile views, source checks, comparisons, favourites, contacts, business claims, trial starts, merchant self-service, and manual operating work are measured because they inform the next product and business decisions.
Technical principles
Keep the product evolvable without overbuilding the first version.
Use a real application database from the start
Live product data belongs in a real database; synthetic data used only for controlled tests can remain isolated.
Measure before automating
Processes that are not yet well understood can initially be handled manually so their real time and cost can be measured before automation is built.
Use existing services where they make sense
Common capabilities such as authentication, payments, or transactional email should normally be integrated from existing services rather than rebuilt unless the product has a specific reason to do so.
Automate real bottlenecks
Automation and scaling work should target observed constraints, not imagined ones.
What this case demonstrates
Technical growth and project responsibility developed in parallel.
LB gave me direct responsibility for product, software, people, vendors, operations, and project execution. Later enterprise experience added the structured planning, estimation, dependency management, and delivery practices I use today.
Those experiences did not replace the technical track; they expanded it. Technical Project / Delivery Management is where software understanding and project responsibility meet.
Today I can work at that intersection: challenge risky assumptions, define a realistic scope, and turn validated decisions into a technically and operationally executable software project.
Working with startups and product teams
From business decisions to an executable software project.
I can work alongside founders, product specialists, incubators, and software teams when business decisions supported by enough evidence have to become technical scope, architecture, planning, team coordination, and implementation.