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 provides a concrete way to show how subsequent experience changed the way I would make the same decisions: first reduce the highest-risk business uncertainties, then translate what has been learned into technical scope 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 therefore not to prove the business before development. It is to gather the minimum evidence needed to make the next investment rational, while keeping unresolved questions explicit.
Decision before development
Proceed, with conditions
Nothing found before development is strong enough to 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 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
The technical and management tracks grew in parallel.
LB gave me real responsibility for product, software, people, vendors, operations, and project execution before I had the structured planning and project-management tools I use today.
Later software and enterprise Agile experience added more formal planning, estimation, dependency management, cross-functional coordination, and review discipline. Technical Project / Delivery Management is the convergence of those two tracks—not a move away from engineering into an unrelated role.
The role I can play today is at that connection point: understand the business and validation context well enough to challenge the riskiest assumptions, then translate sufficiently supported 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 sufficiently supported business decisions have to become technical scope, architecture, planning, team coordination, and implementation.