The First 100 Customers Course #24: How Lodgerin Turned 850 Meetings Into Its First Customer

TL;DR

Lodgerin founder Oscar Rubio says he held roughly 850 prospective-customer meetings before landing his first organizational customer. That customer did not buy the student-housing marketplace he had been pitching. Comillas University called back after several months because its team needed help coordinating incidents and emergencies during student stays.

The useful mechanism is not persistence as an identity. It is a controlled problem-switch loop: keep the buyer narrow, treat every meeting as a search for a live operational burden, permit the problem to change when evidence repeats, sell one bounded workflow, survive institutional procurement, and turn successful delivery into transferred trust. The 850 count, first-customer sequence, six-month contract cycle, and referral attribution are founder-reported rather than independently audited.

What you will build

You will build a problem-switch first-customer system with eight outputs: an operational-burden ledger, a narrow buyer definition, a 40-account list, a seven-field meeting record, a problem-switch gate, a bounded paid-workflow offer, a procurement map, and a reference-led next list. Each output has a pass condition and a stop condition so meeting volume cannot disguise a weak market.

This motion fits B2B software sold into institutions where the founder can identify a responsible role but trust, legal review, insurance, or security make the sale slow. It is particularly useful when the founder has deep service or operating experience and can deliver the first outcome partly by hand. It does not fit a low-price consumer app, a product with immediate self-serve adoption, or a founder who cannot afford a long procurement cycle.

Case snapshot

Element	What the sources support	Evidence limit
Prior evidence	Relocation services for universities and corporations since 2013	External profiles disagree with the podcast's simplified product timeline
2022 wedge	A student-housing marketplace that earned revenue on completed reservations	The legal company and earlier technology existed before this reset
Failure	No reliable availability calendar, followed by owner cancellations	“Thousands” of requests and lost revenue are founder-reported
Buyer	Organizations sending students or employees abroad	The exact first buyer role inside Comillas is not named
Sales activity	About 800 to 850 meetings, including unscheduled university visits	No CRM ledger or contact denominator is public
First customer	Comillas University after a three-to-four-month silence	Customer order, date, price, and result are not independently verified
Problem switch	From housing reservations to incident and emergency coordination	The first contracted scope is not public
Procurement	Roughly six months, including contracts and insurance	Retrospective founder estimate
Next channel	Referrals inside a small network of universities and companies	No attribution split or first-ten customer ledger

The complete SaaS Podcast interview is unusually specific about the sequence but remains a founder account. Independent Spanish funding coverage corroborates the announced €400,000 round in 2023. It does not verify the early meeting count, Comillas contract, or customer attribution. That boundary matters because the course teaches a mechanism, not a precise benchmark every founder should copy.

The model: keep the buyer, change the problem

The causal chain is service evidence → narrow institutional buyer → direct meeting → live operational burden → problem-switch offer → paid procurement → founder-close delivery → referral transfer. The first half discovers what deserves to be sold. The second half proves that the outcome can survive a real buying process and become referenceable.

Lodgerin's initial marketplace asked whether students could reserve housing. Real usage exposed a supply-data problem: properties that looked available were not. The institutions supporting those students carried another burden. When a housing mismatch, payment issue, or emergency occurred, somebody at the university had to coordinate the response across students, landlords, and service providers.

Comillas reportedly ignored the original offer, then returned with that job. This was not random bespoke work. It stayed inside the same mobility environment, served the same institutional buyer, and used knowledge built through years of manual operations. A valid problem switch changes the outcome while preserving credible access and repeated evidence. A panic pivot changes the buyer, market, product, and channel at once.

Step 1: convert operating history into a burden ledger

Start with ten recent cases from your own work, support inbox, consulting projects, or manual service. For each case, record the actor, trigger, current workaround, people involved, consequence, frequency, and person who ultimately owned the decision. Do not start with a feature.

Rubio had almost a decade of relocation operations to inspect. During COVID, he and his operations lead reportedly mapped those processes on paper across an empty office. That history reduced some market risk, but it did not prove which workflow institutions would buy as software. He says he continued to show ideas, ask customers for feedback, and test willingness to pay.

Pass condition: five cases contain the same actor, trigger, and costly consequence. Stop condition: the evidence is only founder intuition, or every case depends on a different buyer and workflow.

Step 2: choose one responsible buyer

“Universities” is not an ICP. It is an account type. Choose the function that becomes responsible when the workflow breaks: international mobility, student services, operations, finance, or another named owner. Then define one event that makes the job urgent.

When [trigger] happens, [role] must [job] using [workaround], which creates [time, money, risk, or delay].

Build a 40-account list where that sentence plausibly applies. Add exclusions before contacts: institutions without international programs, organizations too small to own the workflow, unsupported geographies, and accounts whose process is already outsourced under a long contract. A narrow list makes contradictions visible.

Pass condition: every account can be explained by the same buyer, event, and consequence. Stop condition: the list needs a different value proposition for every institution.

Step 3: use the meeting to find the last real incident

Do not spend the meeting defending a fixed demo. Ask for the last time the process broke. Record the date, who noticed, what happened next, which systems were used, how long the response took, what it cost, and which person owned the cleanup. Then ask what event would make the buyer change the process this quarter.

1. Trigger: the last dated incident.
2. Owner: the person accountable for resolution.
3. Workaround: the people, tools, and handoffs used.
4. Consequence: measurable time, cost, delay, or risk.
5. Existing budget: what is paid for today.
6. Approval path: sponsor, legal, security, finance, signer.
7. Next event: the date urgency could return.

Pass condition: three independent accounts describe the same live burden in their own words. Stop condition: the founder speaks most of the time, or the buyer can discuss only hypothetical interest.

Step 4: permit a problem switch, not an ICP switch

Review evidence after each five meetings. Group notes by trigger, owner, consequence, and paid workaround. Keep the original problem when it repeats. Narrow it when the job is too broad. Switch it when the same buyer repeatedly funds a different outcome.

Comillas is the model for a problem-switch callback. Rubio had visited the university to sell the housing offer. He says he heard nothing for three or four months. The institution later called about emergencies during stays. It was still the same institutional setting, with the same users and service network, but the buyer's urgent job was now visible.

Pass condition: at least three accounts repeat the revised job and one buyer will discuss budget. Stop condition: every meeting requests unrelated custom work, or the proposed switch removes the founder's evidence advantage.

Step 5: sell one bounded operating workflow

Turn the revised job into a paid-proof memo. Name the incident, inputs, responsible operator, response process, outcome date, review cadence, commercial price, and explicit exclusions. If the first version needs a human behind the interface, say so. The buyer is purchasing a result, not a performance of automation.

Avoid an undefined “innovation pilot.” A strong first contract performs one end-to-end job and exposes the riskiest assumption. In Lodgerin's case, the useful proof was not a larger catalogue of housing. It was whether a university could standardize a painful coordination process with the founder's team and technology.

Pass condition: signed money, a named sponsor, operational access, and a dated outcome review. Stop condition: praise, a free experiment without an owner, or a scope that cannot be delivered without building a new company.

Step 6: budget for institutional procurement

Rubio says the first contract required about six months of negotiation, contracts, and insurance. Treat this as a warning, not a standard duration. Before forecasting a deal, map the sponsor, end user, legal reviewer, security owner, insurer, budget owner, procurement lead, and signer.

Give each stakeholder one artifact and one dated action. The sponsor validates the outcome. The user validates the workflow. Legal sees scope and liability. Security sees data flow. Finance sees price and budget. Procurement sees vendor evidence. The signer sees the final commercial decision. A founder-owned checklist is not enough; the buyer must own the next step.

Pass condition: the sponsor confirms the approval path and owns the next action with a date. Stop condition: you complete weeks of legal or security work while no buyer owns a measurable outcome.

Step 7: deliver founder-close and earn a reference

Early institutional delivery is usually part product, part operations, and part trust. Keep an issue log with severity, response owner, resolution, and product implication. Review the intended outcome with the sponsor every week. Separate temporary learning work from permanent, unpriced service.

Ask for a reference only when the customer can describe a before and after. Rubio says referrals became important because universities and companies in the sector speak to one another. Public evidence does not disclose how many referrals occurred or converted, so the reusable gate is a customer-authored outcome, not an assumed network effect.

Which two peer institutions manage the same incident today? Would you introduce us using the result you saw rather than a general recommendation?

Pass condition: a second institution purchases substantially the same workflow. Stop condition: the reference produces only unrelated requests or the first outcome cannot be stated without founder heroics.

What failed, and what the failure means

The missing availability calendar was a product and data-model failure. A marketplace cannot transact reliably when supply availability is unknown. Fixing the feature addressed that failure, but it did not by itself produce the institutional sales motion.

Ignored email and phone outreach was partly an access failure. Rubio responded with physical visits, but 850 meetings are not evidence that door knocking is universally efficient. They show that a high-trust institutional market may require a channel that creates attention and commitment before the product has references.

The original housing pitch was a problem-selection failure for Comillas. The institution's later callback revealed a more urgent job. The correct response was not to discard universities or add arbitrary features. It was to re-scope around the buyer-owned incident.

Your 7-day implementation plan

Day	Action	Required output
1	Write ten real burden cases	One ledger with actor, trigger, workaround, and consequence
2	Select one responsible buyer	One ICP sentence and 20 exclusions
3	Source 40 accounts	Ranked list with reason for fit
4	Draft and review ten research asks	One learning question, no fake personalization
5	Run calls	Seven-field notes with dated incidents
6	Compare the evidence	Keep, narrow, or problem-switch decision
7	Draft the proof offer	Bounded scope, price, owner, outcome, and stakeholder map

At the end of day seven, do not ask whether the market “liked” the idea. Ask whether the same buyer described the same recent burden, whether an accountable person wants the outcome, and whether the buying path is survivable. If not, return to the evidence before increasing volume.

Lead Scorer implementation

Lead Scorer can reproduce the research, qualification, and drafting discipline without pretending to replace founder judgment. Start with the icp-offer-context skill. Supply the buyer, trigger, exclusions, evidence limits, and claims that may be used. The output is a reusable context, not permission to contact everyone in the market.

Next, use daily-vertical-prospecting to build a separate list for the narrow institution type and responsible role. Run icp-scoring-rubric before paid enrichment. Require evidence of the workflow, relevant scale, geography, and role ownership. Use contact-discovery only for confirmed keepers because contact data is the expensive call.

Find 40 [institution type] accounts where [role] owns [trigger]. Exclude [conditions]. Score the account and role before contact discovery. Preserve the source for every fit claim. Do not draft outreach yet.

Create a draft campaign with cold-email-first-touch. The ask is a short research conversation about one observed workflow, not a claim that the product already solves everything. Use outreach-qa-audit before the founder reviews every draft. Do not activate or send the campaign automatically.

After each conversation, store the trigger, workaround, consequence, objection, approval path, and next event. Use reply-triage to separate interest, timing, wrong person, objection, and no. Repeated objections become research inputs and useful Content Studio material. They do not become a reason to manufacture a case study or add unverified proof.

Pass condition: 40 sourced accounts, a scored keeper list, contact discovery only for qualified leads, ten reviewed drafts, and one consistent learning question. Stop condition: the workflow spends credits before fit, invents signals, mixes different buyer problems in one list, or assumes the agent may send without approval.

Checklist

• Ten real operating cases before a feature list.
• One responsible buyer, one trigger, one consequence.
• Forty narrow accounts with explicit exclusions.
• Seven comparable fields for every meeting.
• A three-account threshold before switching the problem.
• One paid workflow with inputs, outcome, date, and exclusions.
• A buyer-owned stakeholder map before procurement work.
• An issue log that separates learning from permanent service.
• A measurable before and after before asking for a reference.
• Human approval before contact spend, messaging, activation, or sending.

Sources and evidence limits

The primary source is the complete SaaS Podcast episode with Oscar Rubio. The current Lodgerin site describes its international mobility platform. An Al Andalus Innovation profile supports the manual-services origin and exposes a timeline nuance: it reports a 2019 seed round, while the podcast emphasizes the 2022 marketplace and post-COVID product reset. The course therefore does not claim that all Lodgerin technology began in 2022.

El Referente independently reported the €400,000 round in December 2023. Oscar Rubio's 2024 year-end post supplies company-reported growth context. Neither source verifies that the first customer caused later revenue.

No public contract, customer case study, CRM export, or audited accounts verifies the 850 meetings, exact first-customer order, Comillas scope, price, implementation, renewal, six-month cycle, referral attribution, early CAC, payback, activation, retention, churn, or expansion. Use the story as a decision system: meetings must change the evidence, and repeated evidence plus a paid outcome must change what gets built.