Question #001

Category: Startup Vision Difficulty: Easy Question: What is Passyn in one sentence?

Short Answer (10–20 seconds): Passyn is a micro-access infrastructure platform. It lets businesses sell controlled short-term access passes — day passes, exam passes, project passes — instead of forcing every user into a monthly subscription.

Expanded Answer (30–60 seconds): Passyn is a micro-access infrastructure platform that enables businesses to sell controlled short-term premium access passes. This helps them earn money from users who cannot commit to full subscriptions, while protecting their premium brand and their recurring revenue model. We are infrastructure, not a marketplace — think Stripe, but for access instead of payments.

Supporting Evidence: Passyn_Context.md — "One-Sentence Pitch"; Passyn_INSL2026_Proposal.pdf §3.1 Confidence: High Missing Information: —

Question #002

Category: Startup Vision Difficulty: Easy Question: What is your long-term vision?

Short Answer (10–20 seconds): We want Passyn to become the global infrastructure layer for controlled access management — for both digital and physical subscription businesses.

Expanded Answer (30–60 seconds): Stripe became the infrastructure layer for payments. Twilio became it for communications. Cloudflare became it for internet delivery. We believe short-term access needs the same kind of layer. Any business that sells time-limited access — software, streaming, gyms, coworking, tuition — should be able to add it with one integration instead of building it themselves.

Supporting Evidence: Passyn_Context.md — "Long-Term Vision"; Passyn_INSL2026_Proposal.pdf §7.2; Passyn_INSL2026_PitchDeck.pdf slide 7 Confidence: High Missing Information: —

Question #003

Category: Startup Vision Difficulty: Easy Question: What is your mission?

Short Answer (10–20 seconds): Our mission is to help subscription businesses earn money from users who would otherwise pay nothing — without damaging their brand or their monthly revenue.

Expanded Answer (30–60 seconds): Today, when a user cannot afford a monthly plan, both sides lose. The user gets no access. The business gets no revenue. Our mission is to close that gap safely. We give businesses a controlled way to sell short-term access so that interested-but-unconverted users finally become paying customers, and monthly plans still stay the best value.

Supporting Evidence: Passyn_Context.md — "The Big Insight", "Hidden Market Opportunity" Confidence: Medium Missing Information: Your documents describe the mission implicitly but never state a formal mission statement. Judges score "Clear vision, mission, and team background." Write one formal sentence and memorise it.

Question #004

Category: Startup Vision Difficulty: Medium Question: What inspired this idea?

Short Answer (10–20 seconds): We kept seeing the same behaviour around us: students who need a learning platform for five days before an exam, and freelancers who need a premium tool for one three-day project. Both walk away from monthly plans.

Expanded Answer (30–60 seconds): The inspiration came from watching how people around us actually behave with subscriptions. A student needs a study platform for five days before an exam. A freelancer needs a premium tool for one client project. A creator needs premium assets for one weekend. Every one of them wanted to pay something. None of them could justify a full month. We realised the problem was not the price — it was the absence of a safe way to sell short.

Supporting Evidence: Passyn_Context.md — "The Core Problem"; Passyn_INSL2026_Proposal.pdf §2.1 Confidence: Medium Missing Information: The three personas are in your documents, but there is no record of a specific founding moment or personal story. A 15-second personal story is worth real marks under "Storytelling" (20 marks). Prepare one true story.

Question #005

Category: Startup Vision Difficulty: Medium Question: Tell us your founder story.

Short Answer (10–20 seconds): Status: Missing Information

Expanded Answer (30–60 seconds): Status: Missing Information. Your documents contain the team names — Dilrukshsn, Sara, Kirushaliny, Sahri and Krivashan — and the parent company Blansyn, but no founder narrative.

Supporting Evidence: Passyn_INSL2026_PitchDeck.pdf slide 1 (team list); Passyn_INSL2026_Proposal.pdf §1.2 (roles are still bracketed placeholders) Confidence: Low Missing Information: Add: (a) how the five of you met and why you formed Blansyn; (b) one true moment where one of you personally hit this problem; (c) why this team, specifically, is the right team. This is the single easiest 3–5 marks you are currently leaving on the table.

Question #006

Category: Startup Vision Difficulty: Medium Question: What is Blansyn and how does Passyn relate to it?

Short Answer (10–20 seconds): Blansyn is our parent company. It builds foundational technology infrastructure — platforms, APIs and digital infrastructure. Passyn is Blansyn's first flagship product.

Expanded Answer (30–60 seconds): Blansyn's long-term vision is to build foundational technology infrastructure products rather than simply using existing technologies. The company aims to create scalable platforms, APIs, AI systems and digital infrastructure that solve large-scale problems. Passyn is one of the first startup products being developed under the Blansyn brand, and our first flagship product.

Supporting Evidence: Passyn_Context.md — "Parent Company"; Passyn_INSL2026_Proposal.pdf §1.1 Confidence: High Missing Information: Whether Blansyn is a legally registered entity is not stated anywhere. A judge may ask. Confirm registration status before the round.

Question #007

Category: Startup Vision Difficulty: Hard Question: Why should a student team be the one to build financial-grade access infrastructure?

Short Answer (10–20 seconds): Because we found the gap first and we already built a working prototype of the whole platform. We are honest that we need senior engineers to harden it, and that is exactly where our first funding and mentorship goes.

Expanded Answer (30–60 seconds): Two reasons. First, we did not just write a document — we have a working four-portal platform with a real API, database and payment flow, which proves we understand the problem deeply. Second, we know our limits. The prototype was built fast with AI-assisted development, and our team is stronger on product and business than on deep engineering. So our plan is not to pretend — it is to use funding and mentorship to bring in experienced engineers to review and finish it.

Supporting Evidence: passyn/docs/ARCHITECTURE.md; passyn/README.md; passyn/apps/web codebase (53 pages, 24 API routes) Confidence: High Missing Information: No hiring plan or named advisors documented. See Q#178.

Question #008

Category: Startup Vision Difficulty: Medium Question: Where do you see Passyn in five years?

Short Answer (10–20 seconds): Serving merchants across South Asia and emerging markets, covering both digital and physical access businesses, with white-label and enterprise offerings under the Blansyn umbrella.

Expanded Answer (30–60 seconds): Our roadmap has three phases. Phase one is the MVP. Phase two is production launch with the full API and payment integrations. Phase three is enterprise expansion — white-label licensing, advanced analytics and global scaling. In five years we want to be the default answer when any business asks "how do I sell a day pass safely?"

Supporting Evidence: Passyn_Context.md — "Future Roadmap"; Passyn_INSL2026_Proposal.pdf §7.2, §8.3 Confidence: Medium Missing Information: No year-by-year five-year plan with targets exists. Only a three-year SOM target of 300–500 merchants and US$0.4–0.6M ARR.

Question #009

Category: Startup Vision Difficulty: Medium Question: How did you discover this problem?

Short Answer (10–20 seconds): By observing behaviour, not by running a survey. We saw students, freelancers and creators all abandon monthly paywalls, share accounts, or turn to piracy — and realised businesses were losing the same money every time.

Expanded Answer (30–60 seconds): We started from the user side. When people face a monthly-only paywall, they walk away, postpone, share accounts, or go to piracy. Then we flipped it and looked at the merchant side, and found five recurring revenue leaks: non-converting users, account sharing, piracy, trial abandonment and delayed purchases. The same behaviour causes all five. That is when we knew this was an infrastructure problem, not a pricing problem.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §2.1, §2.3; Passyn_Context.md — "What Happens Today?", "Why Businesses Need Passyn" Confidence: Medium Missing Information: No formal customer discovery has been done yet. Your own proposal §6.2 states the next step is "structured merchant discovery interviews." Judges score Customer Discovery under a 15-mark criterion. Do at least 5–10 interviews before 8 August if at all possible.

Question #010

Category: Startup Vision Difficulty: Hard Question: Why is now the right time for Passyn?

Short Answer (10–20 seconds): Because subscriptions are still growing fast — from about US$650 billion today to a forecast US$1.2 trillion by 2030 — while subscription fatigue is rising at the same time. The gap is widening every year.

Expanded Answer (30–60 seconds): Three things are true at once right now. The subscription economy keeps expanding. Users are increasingly resisting recurring commitments — subscription fatigue is real and documented. And the infrastructure analogues have already proven the model: Stripe for payments, Twilio for communications, Cloudflare for delivery. The demand exists, the resistance exists, and the playbook exists. What is missing is the layer itself.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §4.2, §6.2; Passyn_INSL2026_PitchDeck.pdf slides 4 & 6 Confidence: High Missing Information: The subscription-fatigue claim has no cited source in your documents. Find one citable statistic before the round — a judge may ask "says who?"

Question #011

Category: Startup Vision Difficulty: Medium Question: What does success look like in the next twelve months?

Short Answer (10–20 seconds): A finished MVP, three to five pilot merchants across SaaS, education and physical access, and real data proving that passes add revenue rather than cannibalising subscriptions.

Expanded Answer (30–60 seconds): Our stated next three to six months are: complete the MVP — merchant dashboard, pass creation, activation, expiry and analytics; onboard three to five pilot merchants across different segments; and validate the protective pricing model with real conversion and pass-sale data. Beyond that, the twelve-month goal is to turn those pilots into paying merchants and prove the unit economics.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §7.1; Passyn_INSL2026_PitchDeck.pdf slide 6 Confidence: High Missing Information: No specific twelve-month numeric targets (merchant count, revenue, passes sold) are documented — only the three-year 300–500 merchant figure.

Question #012

Category: Startup Vision Difficulty: Hard Question: If this idea is so obvious, why has nobody built it?

Short Answer (10–20 seconds): Because everyone approached it as a pricing problem, and pricing solutions cannibalise subscriptions. We approached it as an infrastructure problem with a protective pricing rule, so it adds revenue instead of taking it.

Expanded Answer (30–60 seconds): Businesses cannot simply offer a cheap daily plan — that would cannibalise monthly subscriptions and damage their premium brand. So the obvious version of this idea is genuinely dangerous for merchants, and they correctly avoid it. Our insight is that the problem is not the price, it is the absence of safe infrastructure. By making passes always cost more per day than the monthly plan, and positioning them as a separate premium category, the danger disappears.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §2.3, §3.3; Passyn_Context.md — "The Most Important Strategic Principle", "Pricing Psychology" Confidence: High Missing Information: —

---

2. PROBLEM

Question #013

Category: Problem Difficulty: Easy Question: What exact problem are you solving?

Short Answer (10–20 seconds): Millions of users need premium access occasionally, not continuously. Faced with a monthly-only paywall they walk away — so the user gets nothing and the business earns nothing.

Expanded Answer (30–60 seconds): The modern digital economy runs on monthly subscriptions — Spotify, Netflix, Canva, ChatGPT, Coursera and thousands of SaaS and education platforms. But a large group of users only need premium access temporarily. For them a full monthly plan feels expensive and wasteful. They walk away, postpone, share accounts or turn to piracy. The user was willing to pay something and the business could have earned something, but instead both earn nothing.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §2.1; Passyn_Context.md — "The Core Problem" Confidence: High Missing Information: —

Question #014

Category: Problem Difficulty: Easy Question: Who exactly feels this pain?

Short Answer (10–20 seconds): Two groups at the same time — subscription and SaaS businesses that leak revenue, and "non-converting interested users" who genuinely want the product but cannot commit monthly.

Expanded Answer (30–60 seconds): On the business side: digital platforms, e-learning and exam-prep services, design and productivity tools, AI platforms, streaming and membership services, and increasingly physical access businesses like gyms, coworking spaces, tuition classes and sports clubs. On the user side: people who need a product, value it, and would pay for short-term access, but cannot justify or afford a recurring monthly commitment. Today most subscription businesses earn zero revenue from that entire segment.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §2.2; Passyn_Context.md — "Hidden Market Opportunity" Confidence: High Missing Information: —

Question #015

Category: Problem Difficulty: Medium Question: Who is your actual customer — the business or the end user?

Short Answer (10–20 seconds): The business. Passyn is B2B. We sell to merchants, and they sell passes to their own users. The end user experiences the product but never buys from us directly.

Expanded Answer (30–60 seconds): This matters because it changes everything about our model. We are a B2B infrastructure company. Our customer is the merchant — a SaaS company, an e-learning platform, a gym. They integrate Passyn, create their passes, and keep their brand, their customers and their pricing. We provide the issuing, payment, verification and analytics layer underneath. That is why we say infrastructure, not marketplace.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §4.1; passyn/README.md; Passyn_Context.md — "Target Customers (B2B)", "Key Philosophy" Confidence: High Missing Information: —

Question #016

Category: Problem Difficulty: Medium Question: What do businesses do today instead?

Short Answer (10–20 seconds): Mostly nothing. They offer free trials, and when the trial ends the user either subscribes monthly or disappears. There is no middle option.

Expanded Answer (30–60 seconds): Today the standard toolkit is a free trial, a monthly plan and an annual plan. That works for committed users, but it has no answer for occasional users. Some businesses try discounts, but discounts damage the brand and cannibalise the monthly plan. So most just accept the loss. Our proposal documents five recurring leaks they live with: non-converting users, account sharing, piracy, trial abandonment and indefinitely delayed purchases.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §2.3; Passyn_Context.md — "Why Businesses Need Passyn" Confidence: High Missing Information: —

Question #017

Category: Problem Difficulty: Medium Question: Why do existing solutions fail?

Short Answer (10–20 seconds): Because subscription-management and paywall tools manage recurring billing. None of them are purpose-built for brand-safe, expiring short-term passes with automatic access revocation.

Expanded Answer (30–60 seconds): Most existing tools focus on monthly and annual subscriptions. They handle billing cycles, dunning and renewals very well. But controlled, expiring access is a different problem: it needs an access lifecycle engine, expiry enforcement, usage limits, revocation, and a pricing rule that protects the monthly plan. Very few tools address that as dedicated infrastructure, which is why merchants either build it themselves badly or skip it entirely.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §8.2, §4.3; Passyn_Context.md — "Competitive Advantage" Confidence: Medium Missing Information: No named competitor is analysed anywhere in your documents. See Q#117–#120.

Question #018

Category: Problem Difficulty: Hard Question: Can you quantify the problem in numbers?

Short Answer (10–20 seconds): Status: Missing Information — we can size the market but we have not yet quantified how much revenue an individual merchant loses to non-converting users.

Expanded Answer (30–60 seconds): What we can quantify today is the market: the global subscription economy is roughly US$650 billion in 2025 heading to US$1.2 trillion by 2030, and we estimate 8,000–10,000 access-based businesses in Sri Lanka alone. What we have not yet quantified is the per-merchant loss — how many visitors hit a paywall and leave. That is exactly what our first pilot merchants will measure for us.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §4.2 Confidence: Low Missing Information: This is one of your biggest gaps. You need at least one credible number for paywall abandonment or trial-to-paid conversion rates. Even a public industry benchmark would materially strengthen "Problem Definition" and "Research Depth."

Question #019

Category: Problem Difficulty: Medium Question: What are the five revenue leaks you talk about?

Short Answer (10–20 seconds): Interested users who never convert, account sharing, piracy, free-trial abandonment, and users who delay their purchase indefinitely. All five come from the same missing middle option.

Expanded Answer (30–60 seconds): They are all symptoms of one cause: the only path to premium is a monthly commitment. A user who won't commit becomes a non-converting user. A user who wants cheaper access borrows a friend's login — that is account sharing. A user who cannot pay at all goes to piracy. A trial user who liked it but is not ready abandons. And a user who says "later" says it forever. Passyn gives all five of them a legal, paid path.

Supporting Evidence: Passyn_Context.md — "Why Businesses Need Passyn" (Leaks #1–#5); Passyn_INSL2026_PitchDeck.pdf slide 2 Confidence: High Missing Information: —

Question #020

Category: Problem Difficulty: Hard Question: Is this a real problem or a nice-to-have?

Short Answer (10–20 seconds): It is a structural revenue leak in the fastest-growing part of the global economy. Every subscription business leaks the same five ways, and none of them has a safe tool to stop it.

Expanded Answer (30–60 seconds): The test for "nice-to-have" is whether anyone is losing money today. Here, both sides are. Businesses lose conversions, revenue and future customers. Users lose access and productivity. And the loss compounds, because the subscription model keeps expanding while subscription fatigue grows. The reason it looks like a nice-to-have is that the loss is invisible — it shows up as an empty space in the revenue line, not as a complaint.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §2.3, §4.3; Passyn_Context.md — "What Happens Today?" Confidence: Medium Missing Information: Would be far stronger with one quoted merchant saying it out loud. See Q#009.

Question #021

Category: Problem Difficulty: Medium Question: Give me a specific example of the problem.

Short Answer (10–20 seconds): A student needs a premium study platform for five days before an exam. The only option is a full month. She decides it is not worth it and studies from a free source instead. The platform earns nothing.

Expanded Answer (30–60 seconds): We use three examples consistently. The student who needs a study platform for five days before an exam. The freelancer who needs a premium tool for one three-day client project. The creator who needs premium assets for a single weekend. In all three, the person was ready to pay. The platform had capacity to serve them at almost zero marginal cost. And the transaction still did not happen — only because the smallest unit for sale was one month.

Supporting Evidence: Passyn_INSL2026_PitchDeck.pdf slide 2; Passyn_INSL2026_Proposal.pdf §2.1 Confidence: High Missing Information: —

Question #022

Category: Problem Difficulty: Hard Question: Why can't merchants just build this themselves?

Short Answer (10–20 seconds): They can, but it is a real system — pass issuing, payment, expiry enforcement, revocation, usage limits, webhooks, analytics. Most merchants would rather make one API call than build and maintain all of it.

Expanded Answer (30–60 seconds): This is the same argument Stripe made about payments. Any company could build payment processing — but almost none should. Short-term access is the same: it needs an access lifecycle state machine, correct expiry handling, revocation, usage caps, signed webhooks, settlement logic and reporting. Our whole platform exists so a merchant can replace that with one integration and verify access in a single API call.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §2.4 (Access Engine); passyn/docs/API.md; Passyn_API_Architecture_Guide.pdf §1.3 Confidence: High Missing Information: —

Question #023

Category: Problem Difficulty: Medium Question: What is a "non-converting interested user"?

Short Answer (10–20 seconds): Someone who needs the product, values the product, and would pay something — but cannot justify or afford monthly pricing, or only needs it temporarily. Businesses earn zero from this whole segment today.

Expanded Answer (30–60 seconds): It is the segment sitting between "not interested" and "subscriber." Traditional funnels treat them as failures and try to convert them with discounts or longer trials. We treat them as a separate revenue layer with a different product. That reframing is the heart of Passyn: we are not trying to convert them to monthly, we are trying to monetise them as they are.

Supporting Evidence: Passyn_Context.md — "Hidden Market Opportunity"; Passyn_INSL2026_Proposal.pdf §2.2 Confidence: High Missing Information: No sizing of this segment as a percentage of merchant traffic. See Q#018.

Question #024

Category: Problem Difficulty: Hard Question: How do you know users actually want to pay for short-term access instead of just using free alternatives?

Short Answer (10–20 seconds): The strongest signal is that they already pay for it in the physical world — gym day passes, cinema tickets, event passes. The behaviour exists. Digital products just never offered it.

Expanded Answer (30–60 seconds): Honestly, we have not yet run user surveys, and I will not pretend otherwise. What we do have are behavioural signals: people already buy day passes at gyms, single tickets at cinemas and event passes everywhere, so the willingness to pay for time-boxed access is proven. And the piracy and account-sharing behaviour proves the demand is real — people are going to significant effort to get temporary access. Validating willingness-to-pay in digital is exactly what our pilot merchants are for.

Supporting Evidence: Passyn_Context.md — "Expanded Vision Beyond Digital"; Passyn_INSL2026_Proposal.pdf §6.2 Confidence: Low Missing Information: No user-side survey or willingness-to-pay data exists. High-priority gap.

Question #025

Category: Problem Difficulty: Hard Question: Isn't this problem already solved by free trials?

Short Answer (10–20 seconds): No. A free trial earns zero revenue and ends in the same monthly-or-nothing choice. Trial abandonment is actually one of the five leaks we are fixing.

Expanded Answer (30–60 seconds): Free trials solve a different problem — they remove risk for a user who is considering committing. They do nothing for a user who knows they only need five days. That user finishes the trial, still cannot justify a month, and leaves. So the trial cost the merchant money in server capacity and returned nothing. A paid short-term pass turns that same user into revenue, and it gives the merchant a much better signal about real intent.

Supporting Evidence: Passyn_Context.md — "Revenue Leak #4"; Passyn_INSL2026_Proposal.pdf §2.3 Confidence: High Missing Information: —

---

3. SOLUTION

Question #026

Category: Solution Difficulty: Easy Question: How does Passyn work, step by step?

Short Answer (10–20 seconds): A business integrates Passyn, creates passes with a price and a validity window, and sells them. When a user buys, we activate access, track validity, enforce expiry, revoke automatically and record everything.

Expanded Answer (30–60 seconds): A merchant signs up and completes onboarding. In the dashboard or through the API, they create an access package — for example a one-day exam pass at a set price with a 24-hour window. A user buys it. Passyn activates the access, computes the exact expiry, and gives the merchant a single API call to check "is this user allowed in right now?" When the window closes, access is removed automatically and the merchant gets a webhook. The merchant never writes date logic.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §3.2; Passyn_Context.md — "How Passyn Works"; passyn/docs/API.md (Access section) Confidence: High Missing Information: —

Question #027

Category: Solution Difficulty: Easy Question: What are the main components of the product?

Short Answer (10–20 seconds): Four layers — the Merchant Dashboard, the Access Engine, the API Layer, and the Payment and Analytics layers.

Expanded Answer (30–60 seconds): The Merchant Dashboard is where a business creates passes, sets pricing and duration, and sees analytics and settlements. The Access Engine handles activation, validation, expiry and usage tracking automatically. The API Layer lets developers create, activate, verify and revoke access programmatically. The Payment layer handles card, wallet and local gateways. The Analytics layer reports revenue, conversion, pass performance and customer behaviour.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §3.2; Passyn_Context.md — "Product Architecture"; passyn/docs/ARCHITECTURE.md §1 Confidence: High Missing Information: —

Question #028

Category: Solution Difficulty: Medium Question: What types of passes can a merchant create?

Short Answer (10–20 seconds): Day, Weekend, Weekly, Exam, Project and Custom passes. The merchant sets the name, the duration in hours, the price, and optionally a usage cap.

Expanded Answer (30–60 seconds): In the product these are real pass types in the database — DAY, WEEKEND, WEEKLY, EXAM, PROJECT and CUSTOM. Each pass carries a duration in hours from one hour up to a year, a price, a currency, an optional maximum number of uses, and a publish flag so merchants can draft passes before launching them. So an education platform can build a one-day exam pass and a seven-day revision pass, while a gym builds a day pass — same engine, different configuration.

Supporting Evidence: passyn/apps/web/prisma/schema.prisma (PassType enum, Pass model); passyn/docs/API.md — POST /v1/passes; Passyn_Context.md — "How Passyn Works" Confidence: High Missing Information: —

Question #029

Category: Solution Difficulty: Medium Question: What is your unique value proposition?

Short Answer (10–20 seconds): Brand-safe, pricing-protected short-term monetisation. Passes always cost more per day than the monthly plan, so merchants gain new revenue without any risk to their subscriptions.

Expanded Answer (30–60 seconds): The rule is simple and it is the core innovation. For a Rs.1,000-per-month plan — about Rs.33 a day — our day pass costs Rs.79 to Rs.149, never Rs.33. Monthly stays the best value, so no rational subscriber downgrades. Passes are positioned as a separate premium category, never as a cheap or discount plan. That combination — merchant-first, brand-safe, pricing-protected, API-driven, and working for both digital and physical businesses — is what no existing subscription tool offers.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §3.3; Passyn_INSL2026_PitchDeck.pdf slide 3; Passyn_Context.md — "Pricing Psychology" Confidence: High Missing Information: —

Question #030

Category: Solution Difficulty: Hard Question: Walk me through the customer journey for the merchant.

Short Answer (10–20 seconds): Register, get approved, complete a guided onboarding wizard, build a pass in the visual builder, publish it, then watch analytics and settlements. Developers can do the same through the API.

Expanded Answer (30–60 seconds): A merchant registers and starts in PENDING status until our admin team approves them — that approval gate is deliberate, because we verify businesses before they sell access. Then they go through a five-step onboarding wizard, build their first pass with the visual pass builder, and publish it. From there the dashboard gives them customers, analytics, settlements and webhook management. Nothing about their own product or brand changes.

Supporting Evidence: passyn/apps/web/app/merchant/* (onboarding, passes/create, customers, analytics, settlements, webhooks); prisma/schema.prisma (MerchantStatus, onboardingStep 0–4); passyn/README.md Confidence: High Missing Information: —

Question #031

Category: Solution Difficulty: Medium Question: Walk me through the customer journey for the end user.

Short Answer (10–20 seconds): They browse available passes, buy one through checkout, and immediately see the pass in their account with a live countdown. When it expires, access ends automatically.

Expanded Answer (30–60 seconds): In the subscriber portal a user browses passes, opens one, and buys it through Stripe checkout. The purchase creates the access record, activates it, and computes the expiry from that exact moment. They then see it under "My Passes" with a live countdown showing how long is left. Each pass carries a unique serial number and can produce a QR code for in-person verification. Billing history and profile are in the same portal.

Supporting Evidence: passyn/apps/web/app/app/* (passes, my-passes, billing, profile); passyn/README.md (subscriber portal row); lib/qr-token.ts Confidence: High Missing Information: —

Question #032

Category: Solution Difficulty: Medium Question: What happens the moment a pass expires?

Short Answer (10–20 seconds): Access is settled automatically. The status becomes EXPIRED, the next verification returns "not valid" with a reason, and the merchant receives a pass.expired webhook.

Expanded Answer (30–60 seconds): Expiry is computed as activation time plus the pass duration in hours. We settle it lazily — meaning any time the access record is read, the engine checks whether it should now be expired and settles it there. This means correctness does not depend on a background job running on time. For merchants who want an instant expiry notification, we run a scheduled job that fires the webhook promptly. The merchant's code never does date maths.

Supporting Evidence: passyn/apps/web/lib/access-engine.ts (computeExpiry, resolveStatus, canUse); passyn/docs/ARCHITECTURE.md §2.4; passyn/docs/DEPLOYMENT.md §7 Confidence: High Missing Information: —

Question #033

Category: Solution Difficulty: Hard Question: How do you stop a merchant from destroying their own subscription business with your product?

Short Answer (10–20 seconds): With the pricing rule. Short-term access must always cost more per day than the monthly plan. That makes monthly the best value mathematically, so passes attract new users instead of downgrading existing ones.

Expanded Answer (30–60 seconds): This is the most important strategic principle in the whole company. A company like Spotify would never want a customer thinking "why buy monthly when I can buy one day?" — that would destroy subscription economics. So we enforce two things. First, the price rule: Rs.1,000 a month is about Rs.33 a day, so our day pass is Rs.79 to Rs.149. Second, the language rule: never "cheap plan" or "discount plan," always "Access Pass," "Day Pass," "Exam Pass." Passes become a separate premium category, not a downgrade.

Supporting Evidence: Passyn_Context.md — "The Most Important Strategic Principle", "Language Strategy", "Pricing Psychology"; Passyn_INSL2026_Proposal.pdf §3.3, §5.2 Confidence: High Missing Information: The pricing rule is not yet enforced in software — it is a policy. See Q#034.

Question #034

Category: Solution Difficulty: Hard Question: Is the pricing rule actually enforced by your system, or is it just advice?

Short Answer (10–20 seconds): Right now it is a strong product policy and part of merchant onboarding, not a hard software constraint. Building it into the pass builder as an automatic guardrail is a clear next step.

Expanded Answer (30–60 seconds): I want to be precise here. In the current build, a merchant sets the price and duration freely — the system does not yet compare it to their monthly plan and block an unsafe price. The rule lives in our positioning, our onboarding and our pricing guidance. Turning it into an enforced guardrail — where the merchant enters their monthly price and the builder refuses or warns on any per-day price below it — is one of the highest-value features on our roadmap, because it is our core differentiator.

Supporting Evidence: passyn/apps/web/prisma/schema.prisma (Pass.price, durationHours — no floor constraint); Passyn_Context.md — "Pricing Psychology" Confidence: High Missing Information: No documented plan or timeline for automated enforcement. Add this to your roadmap slide — judges love hearing a founder name a concrete next feature.

Question #035

Category: Solution Difficulty: Medium Question: How is this different from just selling a cheaper plan?

Short Answer (10–20 seconds): A cheaper plan lowers the price for everyone and cannibalises revenue. A pass costs more per day and is time-limited, so it only attracts people who would not have subscribed at all.

Expanded Answer (30–60 seconds): A discount is a downward move — it reduces what existing customers pay and trains the market to wait for sales. A pass is a sideways move — it creates a new product category at a premium per-day rate for people buying flexibility, not savings. The merchant's monthly plan is untouched. That is why we are extremely careful with language: we never say cheap, budget, discount or lower-cost. We say Access Pass, Flex Pass, Project Pass, Controlled Access Window.

Supporting Evidence: Passyn_Context.md — "Language Strategy", "The Big Insight"; Passyn_INSL2026_Proposal.pdf §3.3 Confidence: High Missing Information: —

Question #036

Category: Solution Difficulty: Medium Question: Does Passyn work for physical businesses too?

Short Answer (10–20 seconds): Yes. Gyms, coworking spaces, tuition classes, sports clubs, salons and community organisations. The build already includes QR-code verification and location-based merchant discovery for exactly this.

Expanded Answer (30–60 seconds): The access problem is identical whether the door is digital or physical — someone paid for a window of time and something has to check whether that window is still open. In the current build a pass can generate a short-lived signed QR code, and a merchant has a verification screen to scan it at the door. Merchants also carry a category and a location, and there is a nearby-merchants endpoint. So the same engine serves a streaming platform and a gym.

Supporting Evidence: passyn/apps/web/lib/qr-token.ts; app/api/v1/access/[id]/qr, app/api/v1/access/verify-qr, app/merchant/verify; lib/categories.ts (FITNESS, EDUCATION, CINEMA…); app/api/app/merchants/nearby; Passyn_Context.md — "Expanded Vision Beyond Digital" Confidence: High Missing Information: —

Question #037

Category: Solution Difficulty: Medium Question: How long does it take a merchant to integrate Passyn?

Short Answer (10–20 seconds): For a no-code merchant, minutes — they use the dashboard and never touch the API. For a developer, the core integration is essentially one verification call.

Expanded Answer (30–60 seconds): There are two paths. A gym or tuition class does not integrate at all — they create passes in the dashboard and verify by scanning a QR code. A software merchant installs our Node SDK and calls verify with a user ID and a pass ID; they get back whether it is valid and when it expires. That is the hot path. Everything else — expiry, usage counting, revocation — happens inside our engine, not in their code.

Supporting Evidence: passyn/README.md ("The API in 10 seconds"); passyn/docs/API.md — GET /v1/access/verify; packages/sdk Confidence: High Missing Information: No measured integration time from a real merchant yet.

Question #038

Category: Solution Difficulty: Hard Question: What is the single hardest technical part of your product?

Short Answer (10–20 seconds): The Access Engine — the lifecycle state machine that decides whether access is valid right now. Everything else in the product depends on it being exactly correct.

Expanded Answer (30–60 seconds): It owns the state machine: pending becomes active on activation, active becomes expired at the time limit or usage limit, and either can be revoked. Getting it right means handling idempotent activation, usage counting, and expiry without depending on a cron job running on time. We solved that with lazy settlement — the state is resolved whenever the record is read. The pure logic is separated from the database so it can be unit-tested, and it is one of the modules we do have tests for.

Supporting Evidence: passyn/apps/web/lib/access-engine.ts; tests/unit/access-engine.test.ts; passyn/docs/ARCHITECTURE.md §2.4 Confidence: High Missing Information: —

Question #039

Category: Solution Difficulty: Medium Question: What does a merchant see that they cannot get today?

Short Answer (10–20 seconds): Revenue from users they were losing. Plus analytics they have never had — how many people buy short-term access, which pass types perform, and how many convert onward to monthly.

Expanded Answer (30–60 seconds): Today a merchant sees subscribers and churn. They cannot see the shape of the demand they are rejecting. Passyn gives them revenue figures, activation counts, performance by pass type, and conversion data. That last one is strategically important — it tells them whether a pass buyer eventually becomes a subscriber, which turns Passyn from a revenue line into a customer-acquisition channel.

Supporting Evidence: passyn/docs/API.md — GET /v1/analytics/merchant; Passyn_Context.md — "Analytics Layer"; Passyn_INSL2026_Proposal.pdf §6.3 Confidence: High Missing Information: Pass-to-subscription conversion uplift is listed as a metric to track, but no target or benchmark is set.

---

4. TECHNICAL ARCHITECTURE

Framing note for this whole section. Your honest position: the platform is built and running, it was built rapidly with AI-assisted development, and it needs experienced engineers to review and harden it before production. Say that once, early, and then answer technical questions with confidence. Judges respect a founder who knows their own system and its limits.

Question #040

Category: Technical Architecture Difficulty: Easy Question: Describe your overall architecture in simple terms.

Short Answer (10–20 seconds): One Next.js application serves five surfaces — a public site, four role-based portals and the docs — plus a versioned REST API. Behind it sit PostgreSQL for data and Redis for rate limiting and caching.

Expanded Answer (30–60 seconds): Browsers hit the portals, API clients and SDKs hit the versioned API with an API key, and Stripe hits a dedicated webhook endpoint. All three funnel into shared business logic libraries — the access engine, key handling, rate limiting, webhooks, audit and analytics. Those libraries talk to PostgreSQL through Prisma and to Redis for rate limits. Outside that we use Stripe for payments, Resend for email and Cloudflare R2 for asset storage.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §1 (system diagram); passyn/README.md (mermaid architecture) Confidence: High Missing Information: —

Question #041

Category: Technical Architecture Difficulty: Medium Question: Why a monolith and not microservices?

Short Answer (10–20 seconds): For an MVP a monolith gives us one deploy target, one auth system, a shared design system and zero cross-service latency. We wrote the business logic so the API can be split out later.

Expanded Answer (30–60 seconds): Microservices solve organisational scale problems we do not have yet — we are a five-person team. The cost of premature splitting is very real: distributed transactions, service discovery, duplicated auth, and much slower iteration. So we chose a single Next.js app deliberately. The important detail is that all business logic lives in library modules, not inside route handlers, so extracting the API into a standalone service later is a refactor, not a rewrite.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §1 ("This is intentional for an MVP… the API layer is written so it could be extracted into a standalone service later") Confidence: High Missing Information: No documented trigger point for when to split. Have an answer ready: "when a single team can no longer own the whole codebase, or when the verify endpoint needs to scale independently."

Question #042

Category: Technical Architecture Difficulty: Easy Question: What is your frontend stack?

Short Answer (10–20 seconds): Next.js 14.2 with the App Router, TypeScript in strict mode, Tailwind CSS 3.4 with shadcn-style components, Recharts for charts, and Three.js with GSAP for the landing animation.

Expanded Answer (30–60 seconds): We chose Next.js 14.2 rather than 15 because it is the mature line and avoids React 19 churn — for a first build, stability beats novelty. TypeScript runs in strict mode with no any. The UI components are vendored shadcn-style primitives re-themed with our own tokens, which means we own the component code rather than depending on a library's release cycle. The Three.js hero scene is dynamically imported and client-only, so it never slows the portals.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §2.1 (technology decisions table); passyn/README.md (tech stack) Confidence: High Missing Information: —

Question #043

Category: Technical Architecture Difficulty: Easy Question: What is your backend stack?

Short Answer (10–20 seconds): Next.js server-side route handlers in TypeScript, Prisma 6 as the ORM over PostgreSQL, Redis via ioredis, Zod for validation, and Stripe and Resend for payments and email.

Expanded Answer (30–60 seconds): The backend is the API routes plus the library layer. Every input crosses a Zod schema before it reaches business logic. Prisma gives us type-safe, parameterised database access. Redis handles rate limiting and hot-read caching, with an in-memory fallback so the app still runs in development without it. Stripe handles the money and Resend handles transactional email, and both degrade gracefully to no-ops if their keys are absent.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §2.1; passyn/apps/web/lib/ (db, redis, stripe, email, validators) Confidence: High Missing Information: —

Question #044

Category: Technical Architecture Difficulty: Medium Question: Why PostgreSQL and not a NoSQL database?

Short Answer (10–20 seconds): Because access and money are relational and transactional. Passes belong to merchants, access belongs to users and passes, transactions split revenue. We need real foreign keys and consistency.

Expanded Answer (30–60 seconds): Our data is highly relational — users, merchants, passes, access records, transactions, settlements, webhooks and audit logs all reference each other. We also handle money, so we store amounts as fixed-precision decimals rather than floats, and we need transactional guarantees when a purchase creates both a transaction and an access record. PostgreSQL gives us that plus native enums, JSON columns where we want flexibility, and array columns for API-key permissions.

Supporting Evidence: passyn/apps/web/prisma/schema.prisma (Decimal(12,2), enums, Json metadata, String[] permissions); passyn/docs/ARCHITECTURE.md §4 Confidence: High Missing Information: —

Question #045

Category: Technical Architecture Difficulty: Medium Question: Walk me through your database design.

Short Answer (10–20 seconds): The core is User, Merchant, Developer, Pass, Access and Transaction. Around it sit ApiKey, WebhookEndpoint, WebhookEvent, AnalyticsEvent, AuditLog, Settlement and PlatformSetting.

Expanded Answer (30–60 seconds): A User has one role — admin, merchant, developer or subscriber. A Merchant publishes Passes. A Pass grants Access records to Users. A Transaction pays for a Pass and links to exactly one Access. Money lives in the Transaction, which snapshots the platform fee and the merchant share at purchase time, so later commission changes never rewrite history. Access carries the status, activation time, expiry time, usage count and a unique serial number.

Supporting Evidence: passyn/apps/web/prisma/schema.prisma; passyn/docs/ARCHITECTURE.md §4 (ER diagram) Confidence: High Missing Information: —

Question #046

Category: Technical Architecture Difficulty: Hard Question: How do you handle multi-tenancy? How do you stop one merchant seeing another's data?

Short Answer (10–20 seconds): Row-level tenancy keyed on merchant ID. Every merchant-scoped query goes through service functions that require an explicit merchant context — route handlers never query tenant tables directly.

Expanded Answer (30–60 seconds): The rule is architectural, not just careful coding. Handlers cannot reach tenant tables; they must go through library service functions that demand a merchant context. Access and Transaction records carry a denormalised merchant ID specifically so tenant-scoped queries are indexed and cheap. Admin queries are the only cross-tenant paths in the system, and every one of them is audit-logged. On the API, a not-found error is returned for another tenant's resource, so tenancy also hides existence.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §2.3; prisma/schema.prisma (Access.merchantId, Transaction.merchantId denormalised); passyn/docs/API.md (not_found — "or not yours — tenancy hides others' data") Confidence: High Missing Information: No PostgreSQL row-level security policies as a second safety net. Worth adding when engineers join.

Question #047

Category: Technical Architecture Difficulty: Medium Question: Describe your API.

Short Answer (10–20 seconds): A versioned REST API under /api/v1. Every endpoint takes a bearer API key, validates input with Zod, returns the same response envelope, and carries rate-limit headers. The spec is published as OpenAPI 3.0.

Expanded Answer (30–60 seconds): There are roughly twenty-four endpoints grouped into passes, access, merchants, users, analytics and webhooks. Every response — success or failure — has the same four fields: success, data, error and meta. That consistency matters for integrators. The whole surface is machine-readable at the OpenAPI endpoint, and we ship a zero-dependency typed Node SDK, plus an in-browser playground in the developer portal.

Supporting Evidence: passyn/docs/API.md; passyn/docs/ARCHITECTURE.md §5 (endpoint map); app/api/v1/openapi.json/route.ts; packages/sdk Confidence: High Missing Information: —

Question #048

Category: Technical Architecture Difficulty: Medium Question: What is the single most important API call in your product?

Short Answer (10–20 seconds): GET /v1/access/verify. It answers "is this user allowed in right now?" and returns valid, status, expiry and remaining uses. It is the hot path everything else supports.

Expanded Answer (30–60 seconds): A merchant calls it with a user ID and a pass ID, or an access ID. We return whether it is valid, when it expires and how many uses remain. If it is not valid, we return a human-readable reason like "access has expired" or "access has been revoked," so the merchant can show a good message. There is an optional consume flag that counts the check as one use for usage-limited passes. Expiry is settled at this moment, so their code never does date maths.

Supporting Evidence: passyn/docs/API.md — "GET /v1/access/verify — the hot path"; lib/access-engine.ts Confidence: High Missing Information: No documented latency target for this endpoint. Prepare an answer: sub-100ms is the goal, and it is a single indexed lookup.

Question #049

Category: Technical Architecture Difficulty: Medium Question: How does authentication work?

Short Answer (10–20 seconds): Two separate systems. Humans log in through NextAuth v5 with JWT sessions. Machines authenticate with scoped API keys sent as a bearer token. The two never mix.

Expanded Answer (30–60 seconds): For people, NextAuth v5 issues a JWT session so role checks can run in Edge middleware without a database hit. The config is split into an edge-safe part and a Node-only part that touches Prisma and bcrypt. For software, every /v1 endpoint requires an API key. Portal screens use session-authenticated internal endpoints instead, so the public API stays purely key-authenticated and its semantics stay clean for integrators.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §2.1, §5; lib/auth.ts, lib/auth.config.ts, middleware.ts Confidence: High Missing Information: No multi-factor authentication for merchant or admin accounts. A judge may ask. Answer honestly: "not yet, and it is a launch requirement for admin accounts."

Question #050

Category: Technical Architecture Difficulty: Hard Question: How are API keys stored and validated?

Short Answer (10–20 seconds): A key is shown once at creation. We store a SHA-256 hash as an indexed lookup column plus a bcrypt hash for verification. Lookup is instant; verification is deliberately slow.

Expanded Answer (30–60 seconds): This is a design detail I am proud of. Bcrypt is deliberately slow, which is what you want for verification but makes it useless as a database index. So we store two hashes. The SHA-256 column is unique and indexed, giving an O(1) lookup of which key was presented. Then we verify the presented secret against the bcrypt hash. Keys carry a mode — test or live — scoped permissions, a per-key rate limit, an optional expiry, a usage counter and last-used tracking.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §2.5; prisma/schema.prisma (ApiKey.keyHash unique, secretHash); lib/api-key.ts; tests/unit/api-key.test.ts Confidence: High Missing Information: —

Question #051

Category: Technical Architecture Difficulty: Medium Question: How do you handle authorization — who is allowed to do what?

Short Answer (10–20 seconds): Role-based access control at three layers: Edge middleware checks the role against the portal, each portal layout re-checks on the server, and every API endpoint checks the key's scope.

Expanded Answer (30–60 seconds): Defence in depth, because a single check is a single point of failure. First, Edge middleware reads the role from the JWT and blocks a merchant from ever reaching an admin URL. Second, each portal's server layout independently guards its role — so even if middleware were bypassed, the page would not render. Third, on the API, keys carry scopes like passes:read or access:write, and a request without the required scope gets a 403. Platform analytics require an admin-issued key specifically.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §2.2, §6; middleware.ts; lib/api/guard.ts; passyn/docs/API.md (scope column) Confidence: High Missing Information: —

Question #052

Category: Technical Architecture Difficulty: Medium Question: How does rate limiting work?

Short Answer (10–20 seconds): A sliding-window counter per API key, using Redis increment and expire. Defaults are 100 requests a minute on free and 1,000 on paid, overrideable per key. Every response carries the limit headers.

Expanded Answer (30–60 seconds): Every response includes the limit, the remaining count and the reset timestamp, so a well-behaved integrator never has to guess. On exceeding the limit we return a 429 with a rate-limited code and the reset time in Unix seconds. In production Redis makes the counter consistent across serverless instances. In development, if Redis is not configured, we fall back to an in-process limiter so the whole app still runs — that fallback is a development convenience, not a production strategy.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §2.6; passyn/docs/API.md (rate limiting); lib/rate-limit.ts; tests/unit/rate-limit.test.ts Confidence: High Missing Information: —

Question #053

Category: Technical Architecture Difficulty: Medium Question: How do webhooks work?

Short Answer (10–20 seconds): A merchant registers a URL and the events they want. We sign every delivery with an HMAC signature that includes a timestamp, log every attempt, and let them replay failures from the dashboard.

Expanded Answer (30–60 seconds): We emit five events: pass purchased, activated, expired, revoked, and settlement paid. Each delivery carries a Passyn-Signature header in the same style Stripe uses — a timestamp and an HMAC-SHA256 of the timestamp plus the body. Merchants verify with constant-time comparison and reject anything older than five minutes, which stops replay attacks. Deliveries that fail — non-2xx or an eight-second timeout — appear in the dashboard log and can be replayed. The signing secret is shown exactly once.

Supporting Evidence: passyn/docs/API.md (webhook events, signature format); lib/webhooks.ts; tests/unit/webhooks.test.ts; prisma/schema.prisma (WebhookEndpoint, WebhookEvent) Confidence: High Missing Information: Automatic retry policy with backoff is not documented — only manual replay. Worth adding.

Question #054

Category: Technical Architecture Difficulty: Medium Question: How do payments work?

Short Answer (10–20 seconds): Stripe Checkout, with the result confirmed by a signature-verified webhook. We deliberately do not touch card data — that keeps the PCI burden with Stripe.

Expanded Answer (30–60 seconds): We use Checkout Sessions rather than building a custom card form, which was a deliberate MVP decision: it moves PCI compliance to Stripe and gets us to production faster. When a checkout completes, Stripe calls our webhook, we verify the signature, and only then do we mark the transaction succeeded and activate the access. Merchant settlements are modelled through Stripe Connect. Notably, if Stripe keys are absent the product runs a simulated checkout that settles through the exact same code path — so the whole platform is demonstrable without a Stripe account.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §2.1 (payments row); app/api/webhooks/stripe/route.ts; lib/checkout.ts; passyn/README.md (simulated checkout note); passyn/docs/DEPLOYMENT.md §2 Confidence: High Missing Information: Stripe is not available to merchants in every market. Local Sri Lankan gateway integration is described in your context document as part of the payment layer but is not built. See Q#150.

Question #055

Category: Technical Architecture Difficulty: Hard Question: What happens if the Stripe webhook never arrives?

Short Answer (10–20 seconds): The transaction stays pending and access is not activated, so we never grant access we were not paid for. Recovering a genuinely lost webhook is a gap we have not closed yet.

Expanded Answer (30–60 seconds): Our design fails safe rather than failing open — the access record only becomes active once payment is confirmed. That is the right default. What we have not built is active reconciliation: a scheduled job that queries Stripe for recent sessions and settles anything our database still shows as pending. Stripe also retries webhooks on its side, which covers most cases. I would treat reconciliation as a pre-production requirement.

Supporting Evidence: app/api/webhooks/stripe/route.ts; prisma/schema.prisma (TransactionStatus.PENDING); passyn/docs/DEPLOYMENT.md §7 Confidence: Medium Missing Information: No reconciliation job is documented or built. Honest, specific gap — good to name proactively.

Question #056

Category: Technical Architecture Difficulty: Medium Question: Where is it hosted and deployed?

Short Answer (10–20 seconds): Vercel runs the Next.js app including the API. Railway provides PostgreSQL and Redis. Stripe, Resend and Cloudflare R2 sit outside as managed services.

Expanded Answer (30–60 seconds): The recommended topology is documented step by step: provision Postgres and Redis on Railway, configure Stripe with three webhook events, verify a sending domain on Resend, then deploy the app on Vercel with the root directory set to the web app. Everything is environment-variable driven, so nothing is hardcoded. We also document a single-box alternative — build and run behind nginx or Caddy — so we are not locked to Vercel.

Supporting Evidence: passyn/docs/DEPLOYMENT.md §1–§4, §8; passyn/docs/ARCHITECTURE.md §8 Confidence: High Missing Information: Not currently deployed to a live production URL as far as the documents show. Deploy a demo before 8 August if you possibly can — a live link is worth more than any slide.

Question #057

Category: Technical Architecture Difficulty: Medium Question: How do you deploy changes safely?

Short Answer (10–20 seconds): Schema changes ship as Prisma migrations — created locally, committed, then applied in CI before the deploy. There is a documented post-deploy checklist we run every time.

Expanded Answer (30–60 seconds): The migration discipline matters most: we never push schema changes directly to production, we generate a migration file, commit it, and deploy it. The post-deploy checklist verifies that the OpenAPI spec is served, that an unauthenticated API call returns the correct 401 envelope, that sign-in routes each role to the right portal, that a Stripe test event reaches our webhook, that a real test purchase completes end to end with a receipt email, and that security headers are present.

Supporting Evidence: passyn/docs/DEPLOYMENT.md §5, §6, §7 Confidence: High Missing Information: No CI/CD pipeline configuration is documented — no automated test gate before deploy. A senior engineer would flag this. Name it as a known gap.

Question #058

Category: Technical Architecture Difficulty: Hard Question: How do you monitor the system in production?

Short Answer (10–20 seconds): Today we have application-level observability — an audit log, an append-only analytics event stream, and webhook delivery logs. We do not yet have external monitoring or alerting, and that is a real gap.

Expanded Answer (30–60 seconds): Inside the product we log every sensitive action with the actor and IP address, we record analytics events like pass viewed, purchased, access verified and API request, and every webhook delivery attempt is stored with its status and response code. What we do not have is infrastructure monitoring — no uptime checks, no error tracking service, no alerting when the verify endpoint slows down. For a system whose whole job is answering "is this access valid," that has to be in place before we take real merchants.

Supporting Evidence: lib/audit.ts, lib/analytics.ts, lib/metrics.ts; prisma/schema.prisma (AuditLog, AnalyticsEvent, WebhookEvent) Confidence: High Missing Information: No APM, uptime monitoring, error tracking or alerting is specified. Genuine gap — name it before a judge does.

Question #059

Category: Technical Architecture Difficulty: Medium Question: What do you log, and why?

Short Answer (10–20 seconds): Three streams. An audit log of every sensitive action with actor and IP. An analytics event stream for product behaviour. And a webhook delivery log with attempts and response codes.

Expanded Answer (30–60 seconds): They serve different purposes. The audit log is for accountability — key creation and revocation, merchant approval and suspension, access revocation, settings changes. It answers "who did this?" The analytics stream is append-only and drives merchant reporting. The webhook log is operational — it lets a merchant see exactly which deliveries failed and replay them. Keeping them separate means one does not pollute the other.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §6; prisma/schema.prisma (AuditLog, AnalyticsEvent, WebhookEvent) Confidence: High Missing Information: No log retention policy is documented — relevant to data-protection compliance. See Q#215.

Question #060

Category: Technical Architecture Difficulty: Medium Question: How do you cache, and what do you cache?

Short Answer (10–20 seconds): Redis caches hot reads with short time-to-live values — pass catalogues and analytics rollups. Rate-limit counters also live in Redis. Everything else reads from PostgreSQL directly.

Expanded Answer (30–60 seconds): We are deliberately conservative about caching, because the one thing you must never cache incorrectly is whether access is currently valid. So verification reads live data. What we do cache are things that are expensive and tolerant of being a few seconds stale — a merchant's published pass catalogue, and analytics rollups that would otherwise aggregate large event tables on every dashboard load.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §7; lib/redis.ts Confidence: Medium Missing Information: Specific TTL values and a cache-invalidation strategy are not documented.

Question #061

Category: Technical Architecture Difficulty: Medium Question: Do you use a CDN?

Short Answer (10–20 seconds): Yes — Vercel serves static assets from its edge network, and Cloudflare R2 is our asset storage for merchant logos and uploads.

Expanded Answer (30–60 seconds): Static assets and images go through Vercel's edge, and we use the framework's image optimisation and font loading so assets are served in modern formats and sizes. Merchant-uploaded assets like logos go to Cloudflare R2, with a public URL configured by environment variable. R2 is optional in development — without it, logo uploads accept URLs instead.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §7, §8; passyn/docs/DEPLOYMENT.md §4 (R2 variables); passyn/docs/SETUP.md §3 Confidence: Medium Missing Information: No CDN strategy for the API itself (which is correct — verification must not be cached at the edge).

Question #062

Category: Technical Architecture Difficulty: Hard Question: How do you achieve high availability?

Short Answer (10–20 seconds): The application is stateless, so it scales horizontally and any instance can serve any request. Availability today therefore depends mainly on our managed database and hosting providers.

Expanded Answer (30–60 seconds): Statelessness is the important architectural property — sessions are JWTs, rate-limit state is in Redis, nothing lives in an instance's memory that matters. So instances are disposable and can be added freely. The honest limit is that we have a single database and a single region, so our real availability ceiling is our provider's. Multi-region and read replicas are scaling work we have identified but not done.

Supporting Evidence: passyn/docs/DEPLOYMENT.md §7 ("the app is stateless"); passyn/docs/ARCHITECTURE.md §2.1 (JWT strategy) Confidence: Medium Missing Information: No documented uptime target or SLA, no failover plan, no multi-region strategy.

Question #063

Category: Technical Architecture Difficulty: Hard Question: What is your disaster recovery plan?

Short Answer (10–20 seconds): Status: Missing Information — we rely on our managed database provider's backups, but we have not defined our own recovery objectives or tested a restore.

Expanded Answer (30–60 seconds): Status: Missing Information. Our deployment documentation covers provisioning and migrations but does not define a disaster recovery plan. What I can say is what the architecture gives us: the application is stateless and reproducible from the repository, all configuration is in environment variables, and the database is managed with provider-level backups. What is genuinely missing is our own backup schedule, a stated recovery point and recovery time objective, and a tested restore procedure.

Supporting Evidence: passyn/docs/DEPLOYMENT.md (no DR section) Confidence: Low Missing Information: Add: backup frequency, retention period, RPO/RTO targets, and a documented restore drill. This is a standard investor due-diligence question.

Question #064

Category: Technical Architecture Difficulty: Medium Question: How do you back up data?

Short Answer (10–20 seconds): Status: Missing Information — currently we depend on the managed provider's automatic backups. We have not defined our own backup policy.

Expanded Answer (30–60 seconds): Status: Missing Information. Our documentation specifies Railway-managed PostgreSQL, or alternatives such as Neon or Supabase, all of which provide automated backups. But no backup frequency, retention window or restore test is documented on our side, and for a platform holding transaction records that is not sufficient. It is on the pre-production checklist.

Supporting Evidence: passyn/docs/DEPLOYMENT.md §1 Confidence: Low Missing Information: Define and document a backup and retention policy.

Question #065

Category: Technical Architecture Difficulty: Medium Question: How do you handle database performance?

Short Answer (10–20 seconds): With deliberate indexing on the query paths that matter, denormalised merchant IDs for tenant-scoped queries, and connection pooling as the first scaling lever.

Expanded Answer (30–60 seconds): The schema carries composite indexes chosen for real query patterns — access by user and status, access by merchant and status, access by status and expiry time for settlement sweeps, transactions by merchant, status and date. Access and Transaction both carry a denormalised merchant ID so tenant queries never need a join to filter. On the connection side, serverless platforms open many short-lived connections, so we use the pooled database URL, and our documentation names PgBouncer or a provider pooler as the first knob to turn under load.

Supporting Evidence: prisma/schema.prisma (@@index declarations); passyn/docs/DEPLOYMENT.md §1, §7 Confidence: High Missing Information: No load testing has been done, so no measured throughput figures exist.

Question #066

Category: Technical Architecture Difficulty: Medium Question: What third-party services do you depend on?

Short Answer (10–20 seconds): Stripe for payments, Resend for transactional email, Cloudflare R2 for asset storage, plus Vercel and Railway for hosting and data. All configured by environment variable.

Expanded Answer (30–60 seconds): A design point worth mentioning is that every integration degrades gracefully. Without Stripe keys the purchase flow uses a simulated checkout that settles through the same code path. Without Resend, emails are logged to the console. Without R2, logo uploads accept URLs. Without Redis, rate limiting falls back to in-memory. That means the whole product boots and demonstrates with nothing but a database, which is very useful for development and for demos.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §8; passyn/docs/SETUP.md §3; passyn/README.md Confidence: High Missing Information: No vendor-lock-in mitigation or alternative-provider analysis. See Q#188.

Question #067

Category: Technical Architecture Difficulty: Hard Question: What happens if Stripe goes down?

Short Answer (10–20 seconds): New purchases stop, but existing access keeps working — verification never touches Stripe. So merchants' customers are unaffected, only new sales pause.

Expanded Answer (30–60 seconds): This is an important separation. Payment and access are decoupled. Verification reads our own database; it does not call Stripe. So a Stripe outage means a merchant cannot sell new passes for that period, but every pass already sold continues to work normally and expire correctly. Adding a second payment provider — including local Sri Lankan gateways — is on the roadmap and would reduce even that exposure.

Supporting Evidence: lib/access-engine.ts (verification path); passyn/docs/ARCHITECTURE.md §1; Passyn_Context.md — "Payment Layer" Confidence: High Missing Information: Local gateway support is described as a plan, not built.

Question #068

Category: Technical Architecture Difficulty: Medium Question: How do you handle the four different user types in one application?

Short Answer (10–20 seconds): Four real URL segments — admin, merchant, developers and app — each with its own layout and its own server-side role guard, on top of the Edge middleware check.

Expanded Answer (30–60 seconds): There is an interesting detail here. The original design sketch used Next.js route groups, but route groups do not create URL segments, so four portals each with a dashboard would all collide at the same URL. We corrected that by making the portals real path segments. Each has an isolated layout with its own sidebar, navigation, breadcrumbs and error boundary, plus a server-side role guard in addition to the middleware guard.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §2.2 ("correction to the brief"); app/admin, app/merchant, app/developers, app/app Confidence: High Missing Information: —

Question #069

Category: Technical Architecture Difficulty: Medium Question: How does QR verification work for physical merchants?

Short Answer (10–20 seconds): The user's pass produces a short-lived signed token — valid five minutes — encoded as a QR code. The merchant scans it, we verify the signature in constant time, and return valid or not.

Expanded Answer (30–60 seconds): The token is a signed structure containing the access ID, the pass serial number and an expiry timestamp, signed with HMAC-SHA256. Five minutes is deliberate: it is long enough for someone to walk to the door and short enough that a screenshot shared with a friend is useless within minutes. We compare signatures using constant-time comparison to prevent timing attacks, and any tampering, expiry or malformed token returns the same generic failure so no information leaks.

Supporting Evidence: passyn/apps/web/lib/qr-token.ts; app/api/v1/access/[id]/qr/route.ts; app/api/v1/access/verify-qr/route.ts; app/merchant/verify Confidence: High Missing Information: —

Question #070

Category: Technical Architecture Difficulty: Hard Question: How do you prevent one person buying a day pass and sharing it with ten friends?

Short Answer (10–20 seconds): Three controls. Access is bound to a specific user ID. Passes can carry a maximum-use cap. And the QR token expires in five minutes, so a shared screenshot dies quickly.

Expanded Answer (30–60 seconds): Access is not a code — it is a record tied to a user ID, a pass and a merchant, with a unique serial number. For digital merchants, verification is by user ID, so sharing means sharing an account, which is the merchant's existing problem, not a new one. For usage-limited passes we count each verification against a maximum. For physical merchants, the QR token expires in five minutes and is signed, so it cannot be forged or reused later. Device fingerprinting or concurrent-session limits would be the next layer.

Supporting Evidence: prisma/schema.prisma (Access.userId, serialNumber unique, usageCount; Pass.maxUses); lib/access-engine.ts (canUse); lib/qr-token.ts (300-second expiry) Confidence: High Missing Information: No concurrent-session limiting or device binding. Worth naming as a roadmap item, since anti-sharing is one of your five leaks.

Question #071

Category: Technical Architecture Difficulty: Medium Question: How do you validate input and prevent bad data?

Short Answer (10–20 seconds): Zod schemas on every input boundary, with the same schemas shared between API routes and forms. Anything that fails returns a 422 listing exactly which fields were wrong.

Expanded Answer (30–60 seconds): Sharing schemas between the API and the UI forms is the part that matters — it means the browser and the server enforce identical rules, so there is no gap between what a form allows and what the API accepts. Failures return a consistent validation-error code with a details array naming each bad field, which makes integration much less painful. Underneath, Prisma parameterises every query, so SQL injection is not a surface.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §6; lib/validators/; passyn/docs/API.md (validation_error, 422) Confidence: High Missing Information: —

Question #072

Category: Technical Architecture Difficulty: Medium Question: What testing do you have?

Short Answer (10–20 seconds): Unit tests with Vitest on the pure business logic — the access engine, API keys, rate limiter and webhook signatures — plus a Playwright end-to-end smoke test.

Expanded Answer (30–60 seconds): We deliberately targeted the modules where a bug would be most expensive. The access engine's pure functions take plain data rather than database rows specifically so they are testable without a database. API key hashing, the rate limiter and webhook signature verification are all covered. I will be honest that coverage is not comprehensive across the UI and the full API surface — broadening it is part of what bringing in experienced engineers is for.

Supporting Evidence: passyn/apps/web/tests/unit/ (access-engine, api-key, rate-limit, webhooks); tests/e2e/smoke.spec.ts; passyn/docs/SETUP.md §6 Confidence: High Missing Information: No measured code coverage percentage. No CI gate running these tests automatically.

Question #073

Category: Technical Architecture Difficulty: Medium Question: Do you have API documentation for developers?

Short Answer (10–20 seconds): Yes — a full REST reference, an interactive playground in the developer portal, a machine-readable OpenAPI 3.0 spec, and a typed Node SDK with zero dependencies.

Expanded Answer (30–60 seconds): Developer experience is a real moat for infrastructure companies, so we treated docs as product. There is a public docs site with API, SDK, webhook and example pages. Inside the developer portal there is an in-browser playground where a developer can make live calls with their own key, plus a webhook sandbox and usage analytics. The OpenAPI spec means their tooling can generate clients automatically. Examples are provided in cURL, Python and PHP as well as JavaScript.

Supporting Evidence: passyn/docs/API.md; app/docs/*; app/developers/playground, app/developers/sdks, app/developers/webhooks; app/api/v1/openapi.json; packages/sdk Confidence: High Missing Information: —

Question #074

Category: Technical Architecture Difficulty: Hard Question: Your documents say Idea Stage, but you have a working platform. Which is true?

Short Answer (10–20 seconds): Both, honestly. We registered and submitted as Idea Stage. Since then we have built a working prototype of the full platform. It proves the concept end to end but it is not production-hardened yet.

Expanded Answer (30–60 seconds): I want to be completely straight about this. Our proposal was written at the concept-validation stage. Since submission we built a working prototype — four portals, a versioned API, a real database schema, payments and QR verification. It was built very quickly using AI-assisted development, which is why it exists at all with our team size. What it is not is production-ready: it lacks monitoring, full test coverage and a security review. So we are an Idea Stage team that can show you a running system, and we know exactly what stands between it and real merchants.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §6.1 (concept-validation phase); passyn/ codebase (53 pages, 24 API routes, 71 components) Confidence: High Missing Information: —

Question #075

Category: Technical Architecture Difficulty: Hard Question: Your prototype was AI-generated. Do you actually understand your own codebase?

Short Answer (10–20 seconds): Yes — we made and can defend the architectural decisions. AI accelerated the writing, not the thinking. And I would rather tell you honestly that we need senior engineers than pretend we do not.

Expanded Answer (30–60 seconds): I can walk you through why we chose a monolith over microservices, why the access engine settles expiry lazily instead of relying on a cron job, why API keys are stored with two different hashes, and why portals are real path segments rather than route groups. Those are decisions with reasons, and they are documented. What AI gave us was speed — a five-person student team producing a full platform in weeks. What it does not give us is a production security review or operational experience, and that is precisely where we want to spend our first funding.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §2 (technology decisions with rationale, including documented deviations from the original brief) Confidence: High Missing Information: —

Question #076

Category: Technical Architecture Difficulty: Medium Question: What are the biggest technical weaknesses you know about?

Short Answer (10–20 seconds): No production monitoring or alerting, no CI pipeline, incomplete test coverage, no external security audit, no payment reconciliation job, and no disaster recovery plan.

Expanded Answer (30–60 seconds): I would rather name these than have you find them. The architecture is sound and the core logic is tested, but the operational layer around it is not built: we have no uptime monitoring or error tracking, no automated test gate before deploys, no reconciliation for lost payment webhooks, and no tested restore procedure. None of these are design flaws — they are the work that turns a prototype into a product, and they are what we would hire for first.

Supporting Evidence: Absence of corresponding sections in passyn/docs/DEPLOYMENT.md and ARCHITECTURE.md; tests/ scope Confidence: High Missing Information: —

Question #077

Category: Technical Architecture Difficulty: Medium Question: How would you handle multiple currencies?

Short Answer (10–20 seconds): Passes already carry a currency field, so the data model supports it. Full multi-currency — conversion, settlement and local gateways — is a named item on our future update list, not built.

Expanded Answer (30–60 seconds): Every pass and transaction stores its own currency code, defaulting to USD, and amounts are fixed-precision decimals, so the foundation is right. What is not built is the rest of it: presenting prices in a buyer's local currency, handling conversion rates, and settling to merchants in their own currency. Our internal future-update notes list multi-currency support as a priority, and it matters a lot for a Sri Lanka launch where merchants will price in rupees.

Supporting Evidence: prisma/schema.prisma (Pass.currency, Transaction.currency); passyn/futureUpdate.txt ("multy currency support") Confidence: High Missing Information: No design or timeline for currency conversion or multi-currency settlement.

---

5. PRODUCT DEVELOPMENT

Question #078

Category: Product Development Difficulty: Easy Question: What is in your MVP?

Short Answer (10–20 seconds): Merchant dashboard, pass creation, access activation, access expiry and basic analytics. That is Phase 1 as defined in our roadmap, and the prototype covers all of it.

Expanded Answer (30–60 seconds): Beyond that scope, the current build already includes things Phase 1 did not require: a full versioned REST API, four separate role portals, Stripe checkout with webhooks, QR verification for physical merchants, an audit log, webhook management and a developer playground. So we are ahead of our own Phase 1 definition on features, and behind on production readiness.

Supporting Evidence: Passyn_Context.md — "Future Roadmap" Phase 1; Passyn_INSL2026_Proposal.pdf §7.1; passyn/ codebase Confidence: High Missing Information: —

Question #079

Category: Product Development Difficulty: Easy Question: What is your roadmap?

Short Answer (10–20 seconds): Three phases. Phase 1 is the MVP. Phase 2 is production launch — full API, payment integrations and merchant onboarding. Phase 3 is enterprise expansion — white-label, advanced analytics and global scaling.

Expanded Answer (30–60 seconds): In the next three to six months specifically: complete the MVP, onboard three to five pilot merchants across SaaS, education and physical access, and validate the protective pricing model with real conversion data. Because the prototype already exists, our realistic near-term focus shifts from building features to hardening what we have and getting it in front of real merchants.

Supporting Evidence: Passyn_Context.md — "Future Roadmap"; Passyn_INSL2026_Proposal.pdf §7.1; Passyn_INSL2026_PitchDeck.pdf slide 7 Confidence: High Missing Information: No dates attached to Phase 2 and Phase 3. Judges score "Development Timeline" under a 15-mark criterion. Attach months to each phase before you pitch.

Question #080

Category: Product Development Difficulty: Medium Question: What is the next feature you will build, and why that one?

Short Answer (10–20 seconds): Automated enforcement of the pricing rule inside the pass builder. It is our core differentiator, and right now it is a policy rather than something the software guarantees.

Expanded Answer (30–60 seconds): We tell every merchant that a pass must cost more per day than their monthly plan, because that is what makes us safe rather than cannibalising. But a merchant could ignore that today. If the builder asked for their monthly price and then warned or blocked any unsafe per-day price, our promise becomes a guarantee rather than advice. For an infrastructure company selling trust, turning a policy into an enforced constraint is the highest-value thing we can ship.

Supporting Evidence: Passyn_Context.md — "Pricing Psychology"; prisma/schema.prisma (no price floor constraint on Pass) Confidence: High Missing Information: Not currently on any documented roadmap. Add it — this answer is strong precisely because it shows product judgement.

Question #081

Category: Product Development Difficulty: Medium Question: How do you decide what to build next?

Short Answer (10–20 seconds): By asking what blocks a real merchant from going live. Right now that is production hardening and pricing enforcement, not new features.

Expanded Answer (30–60 seconds): We have more features than we have validation, so adding features is the wrong instinct. The ordering we use is: first, anything that would stop a pilot merchant trusting us with real money — monitoring, reconciliation, security review. Second, anything that protects our core promise — pricing enforcement. Third, anything a pilot merchant explicitly asks for. Features nobody has asked for wait.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §7.1; passyn/docs/DEPLOYMENT.md §6 (pre-production checklist) Confidence: Medium Missing Information: No formal prioritisation framework is documented.

Question #082

Category: Product Development Difficulty: Medium Question: What did you deliberately leave out of the MVP?

Short Answer (10–20 seconds): Custom payment forms, multi-currency, mobile apps, separate developer and merchant subdomains, and third-party social login. All are documented as later work.

Expanded Answer (30–60 seconds): Each omission was a decision. We used Stripe Checkout instead of building card forms, so PCI compliance stays with Stripe. We kept one login portal and one deploy for speed. Our future-update notes list splitting into separate sites for users, merchants and developers, moving docs onto the developer subdomain, and adding third-party sign-in through an identity provider — all sensible, none required to prove the concept.

Supporting Evidence: passyn/futureUpdate.txt; passyn/docs/ARCHITECTURE.md §2.1 (Checkout rationale) Confidence: High Missing Information: —

Question #083

Category: Product Development Difficulty: Hard Question: Why did you build four portals instead of one, for an MVP?

Short Answer (10–20 seconds): Because there are genuinely four different actors with different jobs — our admin team, merchants, developers and end users. Mixing them would have created permission problems that are much harder to unpick later.

Expanded Answer (30–60 seconds): Admin approves merchants and sees platform-wide data. Merchants build and sell passes. Developers manage keys and integrate. End users buy and use passes. Their needs barely overlap, and the security boundaries between them are the whole point of a multi-tenant platform. Building it right the first time cost us more upfront but means role separation is enforced at three layers rather than bolted on. Our future notes do say we should eventually split these onto separate subdomains and stop sharing one login portal.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §1, §2.2; passyn/futureUpdate.txt ("avoid same login portal for everyone") Confidence: High Missing Information: —

Question #084

Category: Product Development Difficulty: Medium Question: Can you demo the product?

Short Answer (10–20 seconds): Yes. It runs with just a database, and seeded demo data gives us an admin, three merchants, fifteen passes and twenty users. The purchase flow works without Stripe keys through a simulated checkout.

Expanded Answer (30–60 seconds): That last point is worth stressing — the simulated checkout settles through exactly the same code path as the real Stripe webhook, so a demo exercises the genuine production logic rather than a fake. We can show a merchant creating a pass, a user buying it, the live countdown, verification returning valid, and then the same verification returning expired.

Supporting Evidence: passyn/docs/SETUP.md §4, §5 (seed contents, demo accounts); passyn/README.md (simulated checkout) Confidence: High Missing Information: Not deployed to a public URL. With a 3-minute pitch you will not demo live, but a 30-second screen recording or a live link in your slides would be very strong.

Question #085

Category: Product Development Difficulty: Medium Question: How long did it take to build what you have?

Short Answer (10–20 seconds): Status: Missing Information — no build timeline is recorded in the documents. What is visible is that the codebase and its documentation were produced over roughly two months.

Expanded Answer (30–60 seconds): Status: Missing Information. The repository documentation is dated June 2026 and the API architecture guide July 2026, which suggests a short and intense build period with AI-assisted development. But no development log or effort estimate exists in your documents, so I cannot give a defensible number.

Supporting Evidence: File dates in passyn/docs/; Passyn_API_Architecture_Guide.pdf (dated July 2026) Confidence: Low Missing Information: Record your actual timeline. "We built this in X weeks with five students and AI assistance" is a memorable, high-impact line.

Question #086

Category: Product Development Difficulty: Medium Question: What is the merchant onboarding experience?

Short Answer (10–20 seconds): A guided wizard with five steps, tracked in the database, plus an admin approval gate. A merchant stays pending until we approve them, then progresses through onboarding to live.

Expanded Answer (30–60 seconds): The approval gate is deliberate. Anyone selling access through us represents us, so we verify the business first. After approval the merchant works through an onboarding wizard whose progress is stored, so they can leave and come back. It ends with them publishing a first pass. For a platform where trust is the product, a slightly slower onboarding with human verification is the right trade.

Supporting Evidence: prisma/schema.prisma (MerchantStatus PENDING/APPROVED/…, onboardingStep 0–4, onboardingDone); app/merchant/onboarding; app/admin/merchants Confidence: High Missing Information: No documented verification criteria for approving a merchant. See Q#213.

Question #087

Category: Product Development Difficulty: Medium Question: How will you know the product is working?

Short Answer (10–20 seconds): Five metrics: merchants onboarded, passes sold, pass-to-subscription conversion uplift, gross pass volume, and net revenue retention.

Expanded Answer (30–60 seconds): Conversion uplift is the one that decides whether the company works. If merchants can see that pass buyers eventually become subscribers — or at minimum that pass revenue is incremental rather than cannibalised — then we are not a feature, we are a growth channel. Net revenue retention tells us whether merchants expand their usage over time, which is the real health signal for any infrastructure business.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §6.3; Passyn_INSL2026_PitchDeck.pdf slide 6 Confidence: High Missing Information: No target values for any of the five metrics.

Question #088

Category: Product Development Difficulty: Hard Question: What would make you kill or pivot this product?

Short Answer (10–20 seconds): If pilot data showed passes genuinely cannibalise subscription revenue rather than adding to it. That is the assumption everything rests on, and it is exactly what the pilots test.

Expanded Answer (30–60 seconds): Our entire promise to merchants is that passes are additive. If three pilots across different segments all showed that pass buyers were mostly people who would otherwise have subscribed monthly, then we are a cannibalisation tool with better branding, and no amount of engineering fixes that. The second kill signal would be merchants agreeing with the idea but refusing to integrate — that would mean the pain is real but not painful enough, which is a slower death.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §8.1 (risk: "proving passes grow rather than cannibalise revenue"), §7.1 Confidence: High Missing Information: —

---

6. BUSINESS MODEL

Question #089

Category: Business Model Difficulty: Easy Question: How do you make money?

Short Answer (10–20 seconds): Five streams. A monthly SaaS fee from merchants, a commission on every pass sold, enterprise plans, white-label licensing, and premium analytics.

Expanded Answer (30–60 seconds): The two that matter at launch are the SaaS fee and the commission. The SaaS fee is a low entry price to drive adoption. The commission scales our revenue with our merchants' success, which aligns us with them — we only grow when they sell more. The other three, enterprise, white-label and premium analytics, are how we grow revenue per merchant later without needing more merchants.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §5.1; Passyn_Context.md — "Revenue Model"; Passyn_INSL2026_PitchDeck.pdf slide 5 Confidence: High Missing Information: —

Question #090

Category: Business Model Difficulty: Hard Question: What exactly do you charge? Give me the numbers.

Short Answer (10–20 seconds): Status: Missing Information — the model is a hybrid low SaaS fee plus commission, and the code carries a 5% default platform fee, but no price points are set in the business documents.

Expanded Answer (30–60 seconds): Status: Missing Information. Here is exactly where we stand. The model is defined: a low entry SaaS fee plus a transaction commission. The platform has three merchant tiers — Starter, Growth and Enterprise — and the default commission in the system is 5%, set per merchant in basis points. What we have not published is the monthly price for each tier. That is a decision we want to make with pilot merchant data rather than guess at.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §5.2; prisma/schema.prisma (MerchantPlan STARTER|GROWTH|ENTERPRISE, commissionBps @default(500)) Confidence: Low Missing Information: This is your single most likely business question and you currently cannot answer it with numbers. Decide three tier prices before 8 August. Even provisional numbers with a stated rationale beat "we haven't decided."

Question #091

Category: Business Model Difficulty: Medium Question: What commission do you take?

Short Answer (10–20 seconds): The system default is 5% of each pass sold, configurable per merchant. The revenue split is snapshotted on every transaction so later rate changes never rewrite past records.

Expanded Answer (30–60 seconds): The commission is stored per merchant in basis points, defaulting to 500 — that is 5%. Every transaction records the platform fee and the merchant share at the moment of purchase, which matters for accounting integrity: if we renegotiate a merchant's rate next year, last year's records still show what actually happened. Larger merchants would negotiate lower rates, which is standard for this model.

Supporting Evidence: prisma/schema.prisma (Merchant.commissionBps @default(500), Transaction.platformFee/merchantShare); passyn/docs/ARCHITECTURE.md §4 Confidence: Medium Missing Information: The 5% figure appears only in code, not in any business document. Confirm it is your intended business rate, then put it in your deck.

Question #092

Category: Business Model Difficulty: Medium Question: Why a hybrid model instead of pure commission or pure SaaS?

Short Answer (10–20 seconds): Pure SaaS gives us predictable revenue but a high barrier to adoption. Pure commission has zero barrier but no floor. Hybrid gives us a low entry price plus upside that scales with merchant success.

Expanded Answer (30–60 seconds): For a new infrastructure company, adoption is the hardest problem, so the entry fee has to be low enough that trying us is an easy decision. But if we were pure commission, a merchant with few sales would cost us support time and return nothing. The hybrid solves both: the low SaaS fee covers our baseline cost to serve, and the commission means our revenue grows automatically as merchants succeed — which also aligns our incentives with theirs.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §5.2; Passyn_INSL2026_PitchDeck.pdf slide 5 Confidence: High Missing Information: —

Question #093

Category: Business Model Difficulty: Medium Question: What is your cost structure?

Short Answer (10–20 seconds): Cloud infrastructure and the access engine, product engineering and maintenance, payment-gateway fees, merchant onboarding and support, and go-to-market.

Expanded Answer (30–60 seconds): The important characteristic is that we are an API-first software platform, so the marginal cost of one additional merchant or one additional pass is very low. Our costs are largely fixed — engineering and infrastructure — with payment-gateway fees being the main variable cost. That gives us strong gross margins and real operating leverage as we scale, which is the whole attraction of the infrastructure model.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §5.3 Confidence: Medium Missing Information: No actual cost figures exist — no monthly infrastructure cost, no salary assumptions, no gateway fee percentage. See Q#149.

Question #094

Category: Business Model Difficulty: Hard Question: What are your unit economics per merchant?

Short Answer (10–20 seconds): Status: Missing Information — we have not yet calculated revenue per merchant, cost to serve, acquisition cost or payback period.

Expanded Answer (30–60 seconds): Status: Missing Information. What I can give you is the shape. Revenue per merchant is the monthly SaaS fee plus 5% of their pass volume. Cost to serve is close to zero at the margin because we are software, with payment-gateway fees as the main variable. But without pilot data I have no real numbers for average pass volume per merchant, and without a marketing spend I have no acquisition cost. Those are the first two things our pilots will produce.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §5.3 Confidence: Low Missing Information: Investor-critical gap. You can derive a defensible estimate: if 300–500 merchants produce US$0.4–0.6M ARR, that implies roughly US$1,000–1,300 ARR per merchant. Work that number out and be ready to say it.

Question #095

Category: Business Model Difficulty: Hard Question: When do you become profitable?

Short Answer (10–20 seconds): Status: Missing Information — no break-even analysis exists in our documents.

Expanded Answer (30–60 seconds): Status: Missing Information. We have a three-year revenue target of US$0.4–0.6 million from 300–500 merchants, and a cost structure described qualitatively, but we have not built a financial model that identifies a break-even point. For a team at Idea Stage with no funding, that is an honest gap, but it is one a judge will notice.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §4.2, §5.3 Confidence: Low Missing Information: Build even a simple three-year model: fixed monthly costs, revenue per merchant, merchant growth curve, and the month where the lines cross.

Question #096

Category: Business Model Difficulty: Medium Question: What is white-label licensing and who buys it?

Short Answer (10–20 seconds): Large businesses license the whole platform under their own brand instead of using ours. It suits enterprises that want the capability but not a visible third-party dependency.

Expanded Answer (30–60 seconds): A large streaming service or an education group with many sub-brands would not want passes visibly powered by an outside company. White-label lets them run the access infrastructure under their own name. Commercially this is attractive because it is high value per contract and low support volume — and strategically it embeds us deep into a large customer's stack.

Supporting Evidence: Passyn_Context.md — "Revenue Model" (White-Label Solutions); Passyn_INSL2026_Proposal.pdf §5.1; roadmap Phase 3 Confidence: Medium Missing Information: No pricing, contract structure or target customer named for white-label.

Question #097

Category: Business Model Difficulty: Medium Question: What are premium analytics and why would a merchant pay extra?

Short Answer (10–20 seconds): Advanced reporting and conversion intelligence — beyond basic revenue numbers, showing which passes drive onward subscriptions and which customer behaviours predict conversion.

Expanded Answer (30–60 seconds): Basic analytics tell a merchant what happened. Conversion intelligence tells them what to do — which pass types to promote, which buyers are likely to upgrade to monthly, and where the revenue uplift is actually coming from. That is data no merchant currently has about their short-term demand, because nobody has ever sold to that segment before. It is a natural upsell because it becomes more valuable the more passes they sell.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §5.1; Passyn_Context.md — "Analytics Layer"; passyn/docs/API.md (/v1/analytics/merchant) Confidence: Medium Missing Information: No feature list distinguishing standard from premium analytics.

Question #098

Category: Business Model Difficulty: Hard Question: Isn't a 5% commission plus Stripe's fees too expensive for merchants?

Short Answer (10–20 seconds): It is 5% of revenue they were earning nothing from. This is not a fee on existing sales — it is a share of a new revenue line that did not exist.

Expanded Answer (30–60 seconds): That framing is everything. If we charged 5% on a merchant's monthly subscriptions, that would be expensive. But passes are sold to non-converting users — people who were going to pay zero. So 95% of something new is strictly better than 100% of nothing. The comparison a merchant should make is not "5% versus 0%," it is "this revenue versus no revenue, and no engineering cost to get it."

Supporting Evidence: Passyn_Context.md — "Hidden Market Opportunity", "The Big Insight"; prisma/schema.prisma (commissionBps) Confidence: High Missing Information: —

Question #099

Category: Business Model Difficulty: Medium Question: How do merchants get paid?

Short Answer (10–20 seconds): Through settlements. Each transaction records the merchant's share, and settlements are recorded per merchant for a period, moving to paid when the transfer is made.

Expanded Answer (30–60 seconds): The database tracks each settlement with an amount, currency, status, period start and end, paid date and a transfer reference. In the current build settlements are recorded in the database. In production, payouts run through Stripe Connect transfers on a scheduled job — our deployment notes specify a monthly run. Merchants see their settlements in their dashboard.

Supporting Evidence: prisma/schema.prisma (Settlement model, Merchant.stripeAccountId, payoutsEnabled); passyn/docs/DEPLOYMENT.md §7; app/merchant/settlements Confidence: High Missing Information: Settlement frequency and minimum payout threshold are not defined as business policy.

Question #100

Category: Business Model Difficulty: Hard Question: You hold merchants' money between purchase and settlement. Isn't that regulated?

Short Answer (10–20 seconds): That is why we use Stripe Connect rather than holding funds ourselves. The money flows through the regulated payment processor, not through a Passyn bank account.

Expanded Answer (30–60 seconds): Handling other people's money directly would make us a payments business with all the licensing that implies, and that is not what we want to be. Stripe Connect exists precisely so platforms can route funds to merchants without becoming money transmitters. Our database records the split for reporting; the actual movement is Stripe's. That said, I would want a proper legal review of this structure for Sri Lanka specifically before we take real money.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §2.1 ("Stripe Connect modeled for merchant settlements"); prisma/schema.prisma (stripeAccountId, payoutsEnabled) Confidence: Medium Missing Information: No legal or regulatory review has been done. See Q#216.

Question #101

Category: Business Model Difficulty: Medium Question: What are your merchant plan tiers?

Short Answer (10–20 seconds): Three tiers — Starter, Growth and Enterprise. They differ in commission rate, API rate limits and support level. Starter is the default for a new merchant.

Expanded Answer (30–60 seconds): The tiers are real in the system, and the rate limits already differ: 100 API requests per minute on the free tier and 1,000 on paid, with custom limits for enterprise. Commission is set per merchant, so it can be negotiated down as volume grows. Enterprise adds custom integrations and dedicated support. What is not yet decided is the monthly price of each tier.

Supporting Evidence: prisma/schema.prisma (MerchantPlan); passyn/docs/API.md (rate limits by tier); Passyn_INSL2026_Proposal.pdf §5.1 Confidence: Medium Missing Information: Tier pricing and a definitive feature matrix. See Q#090.

Question #102

Category: Business Model Difficulty: Hard Question: What stops a merchant using you for six months, learning how it works, then building it themselves?

Short Answer (10–20 seconds): For most merchants the maths never works — building and maintaining it costs far more than our fee. The ones large enough to build it are exactly who we sell white-label to.

Expanded Answer (30–60 seconds): A merchant would need to build and maintain an access lifecycle engine, expiry handling, revocation, usage limits, signed webhooks, settlement logic, analytics and a merchant-facing dashboard — then keep it running and secure forever. For almost every business that is more expensive than a small monthly fee and 5%. For the handful large enough that it does make sense, we do not fight them; we offer white-label licensing so they get their own brand and we keep the revenue. And over time our accumulated data on what pricing actually converts becomes something they cannot rebuild.

Supporting Evidence: Passyn_Context.md — "Revenue Model" (White-Label); passyn/docs/ARCHITECTURE.md (system scope) Confidence: Medium Missing Information: No formal moat analysis exists in your documents. This answer is constructed from documented facts but is not written down anywhere. Worth writing down.

Question #103

Category: Business Model Difficulty: Medium Question: Is this a marketplace? Will you aggregate demand?

Short Answer (10–20 seconds): No. We are explicit that Passyn is not a marketplace, not a reseller, not an account-sharing platform and not a discount platform. Merchants keep their brand, customers and pricing.

Expanded Answer (30–60 seconds): This distinction is central to why merchants would trust us. A marketplace competes with its merchants for the customer relationship. Infrastructure does not. The merchant's users buy from the merchant; we provide the layer underneath. That said, the build does include merchant categories and a nearby-merchants discovery endpoint, so there is a consumer-facing discovery capability if we ever chose to use it — but that would be a strategic change, not the current position.

Supporting Evidence: Passyn_Context.md — "Key Philosophy"; passyn/README.md ("infrastructure, not a marketplace"); lib/categories.ts, app/api/app/merchants/nearby Confidence: High Missing Information: Note the tension: your product has consumer discovery features that a sharp judge could read as marketplace behaviour. Have the answer above ready.

---

7. MARKET

Question #104

Category: Market Difficulty: Easy Question: What is your TAM?

Short Answer (10–20 seconds): The global subscription economy — roughly US$650 billion in 2025, forecast to pass US$1.2 trillion by 2030. Every business in it is a potential Passyn merchant.

Expanded Answer (30–60 seconds): Within that, global SaaS alone is projected to grow from about US$408 billion in 2025 to US$819 billion by 2030. We use the subscription economy as our TAM rather than SaaS alone because our product also serves streaming, membership, education and physical access businesses — anywhere access is sold by time.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §4.2; Passyn_INSL2026_PitchDeck.pdf slide 4 Confidence: High Missing Information: No source is cited for either figure. A judge from Lankan Angel Network may well ask. Find and note the source before 8 August.

Question #105

Category: Market Difficulty: Easy Question: What is your SAM?

Short Answer (10–20 seconds): South Asia and comparable emerging markets — an estimated US$25 to 30 billion in annual access-based spend across subscription, SaaS, education and membership businesses.

Expanded Answer (30–60 seconds): We chose this as our serviceable market because these are the regions where price sensitivity is highest and demand for flexible short-term access is strongest. In a high-income market a monthly subscription is an easy purchase. In South Asia it often is not, which makes the non-converting segment proportionally much larger — and that is exactly the segment we monetise.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §4.2; Passyn_INSL2026_PitchDeck.pdf slide 4 Confidence: Medium Missing Information: The US$25–30 billion figure is described as an estimate with no stated derivation. Be ready to explain how you got there, or say clearly that it is a top-down estimate.

Question #106

Category: Market Difficulty: Medium Question: What is your SOM?

Short Answer (10–20 seconds): Sri Lanka. We estimate 8,000 to 10,000 access-based businesses locally, and target 300 to 500 merchants within three years, producing roughly US$0.4 to 0.6 million in annual recurring revenue.

Expanded Answer (30–60 seconds): The supporting context is that Sri Lanka has over 11 million internet users, an e-commerce market of about US$2.65 billion in 2025, and digital payment volumes projected to reach US$8.56 billion by 2029. The 8,000 to 10,000 businesses include SaaS startups, e-learning and tuition platforms, gyms, coworking spaces and clubs. Our three-year target is 3 to 6% of that, which we consider realistic rather than optimistic.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §4.2; Passyn_INSL2026_PitchDeck.pdf slide 4 Confidence: High Missing Information: How the 8,000–10,000 business count was derived is not documented. Prepare your method.

Question #107

Category: Market Difficulty: Hard Question: How did you calculate the US$0.4–0.6 million ARR figure?

Short Answer (10–20 seconds): It comes from 300 to 500 merchants paying SaaS fees plus transaction commissions. That implies roughly US$1,000 to 1,300 in annual revenue per merchant.

Expanded Answer (30–60 seconds): Working backwards is the honest way to present it: the target is 300 to 500 merchants and US$0.4 to 0.6 million ARR, which is about US$1,000 to 1,300 per merchant per year — say US$80 to 110 a month from the SaaS fee plus commission combined. That is a modest figure per merchant, which is deliberate; we would rather under-promise per account and prove the volume.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §4.2 (arithmetic derived from the stated merchant count and ARR range) Confidence: Medium Missing Information: The derivation is not written down anywhere. The per-merchant figure above is arithmetic on your own numbers, not a documented assumption. Write down your assumed split between SaaS fee and commission.

Question #108

Category: Market Difficulty: Medium Question: Why start in Sri Lanka?

Short Answer (10–20 seconds): It is our home market, so we can meet merchants in person. It is small enough to reach meaningfully, and price sensitivity there makes the short-term access problem sharper than in wealthy markets.

Expanded Answer (30–60 seconds): Three reasons. Access — we are here, we can walk into a gym or a tuition centre and sign them up, which matters enormously for a first infrastructure product that needs deep customer feedback. Fit — high price sensitivity means the non-converting segment is proportionally larger, so the value we add per merchant is bigger. And scale — 8,000 to 10,000 target businesses is small enough that 300 merchants is a visible, defensible position rather than a rounding error.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §4.1, §4.2; Passyn_INSL2026_PitchDeck.pdf slide 4 Confidence: High Missing Information: —

Question #109

Category: Market Difficulty: Medium Question: Who are your target customer segments, in priority order?

Short Answer (10–20 seconds): First, digital subscription and SaaS companies, online education and exam-prep platforms, AI and productivity tools, and membership and streaming services. Second wave: gyms, coworking spaces, tuition classes and sports clubs.

Expanded Answer (30–60 seconds): The digital segments come first because integration is fastest — a developer makes one API call. The physical segment comes second because it needs the QR verification flow and in-person sales, but it is arguably the easier sell: a gym owner instantly understands a day pass. Interestingly, our build already supports both, with merchant categories covering streaming, cinema, anime, TV, fitness and education.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §4.1; Passyn_Context.md — "Target Customers (B2B)", "Expanded Vision Beyond Digital"; lib/categories.ts Confidence: High Missing Information: No documented ranking of which segment to attack first with which message.

Question #110

Category: Market Difficulty: Hard Question: Which single segment would you pick if you could only serve one?

Short Answer (10–20 seconds): Education and exam prep. The pain is sharpest — students genuinely need five days before an exam — the willingness to pay is real, and it is our clearest, most memorable story.

Expanded Answer (30–60 seconds): Exam-driven demand is naturally short-term and seasonal, which is exactly the shape our product is built for. It also has the strongest emotional pull for a merchant: a tuition platform knows exactly how many students look at their pricing page in exam season and leave. And our own seed data includes an education merchant, so it is the segment we have modelled most closely. That said, this is my judgement, not a documented decision.

Supporting Evidence: Passyn_Context.md — "How Passyn Works" (Education Platform examples); Passyn_INSL2026_Proposal.pdf §2.1; passyn/docs/SETUP.md (demo merchant studyprep.dev) Confidence: Medium Missing Information: No beachhead segment is formally chosen in your documents. Judges reward focus. Pick one and say it with conviction.

Question #111

Category: Market Difficulty: Medium Question: Is your market growing or shrinking?

Short Answer (10–20 seconds): Growing sharply. The subscription economy is forecast to roughly double from US$650 billion to US$1.2 trillion by 2030, and every new subscription business creates the same non-converting segment.

Expanded Answer (30–60 seconds): There is a second growth vector too. Subscription fatigue is rising at the same time, which means the proportion of users refusing to commit monthly is growing even faster than the market itself. So our addressable segment grows on both axes — more subscription businesses, and a larger share of their traffic refusing to subscribe.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §4.2, §4.3; Passyn_INSL2026_PitchDeck.pdf slides 4, 6 Confidence: High Missing Information: Subscription fatigue is asserted without a cited source. See Q#010.

Question #112

Category: Market Difficulty: Hard Question: Sri Lanka is small. How is this a venture-scale business?

Short Answer (10–20 seconds): Sri Lanka is the beachhead, not the market. We are infrastructure — the same API serves a merchant in Colombo or Karachi. Expansion across South Asia is a distribution problem, not a rebuild.

Expanded Answer (30–60 seconds): We start in Sri Lanka because that is where we can learn fastest and where being local is an advantage. But nothing about the product is Sri Lanka-specific: the access engine, the API and the pricing rule work identically anywhere. Our SAM across South Asia and comparable emerging markets is US$25 to 30 billion in annual access-based spend. The path is: prove it here, then expand regionally, then add white-label and enterprise under the Blansyn umbrella.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §4.1, §4.2, §8.3 Confidence: High Missing Information: No expansion sequencing — which country second, and why.

Question #113

Category: Market Difficulty: Medium Question: Who are your user personas?

Short Answer (10–20 seconds): On the end-user side: the student before an exam, the freelancer on a short project, the creator with a weekend job, and the casual occasional user. On the merchant side, four roles inside the product.

Expanded Answer (30–60 seconds): The four end-user personas drive demand but are not our customers. Our actual buyer personas map to the portals we built: the merchant owner who creates and prices passes, the developer who integrates, and our own admin team who approves merchants. The end user experiences the pass but the purchasing decision sits with the merchant.

Supporting Evidence: Passyn_Context.md — "The Core Problem" (four user types); passyn/README.md (four actor roles) Confidence: Medium Missing Information: No formal user persona document exists — no demographics, budgets, decision criteria or objections per persona. This was on your requested document list and is genuinely absent.

Question #114

Category: Market Difficulty: Hard Question: How many merchants do you need before this business works?

Short Answer (10–20 seconds): Our stated three-year target is 300 to 500 merchants for US$0.4 to 0.6 million ARR. The number needed to be sustainable rather than successful is not yet calculated.

Expanded Answer (30–60 seconds): Honestly, we can tell you the target but not the break-even count, because we have not built a cost model. Working from our own figures, roughly US$1,000 to 1,300 per merchant per year means every hundred merchants is around US$100,000 to 130,000 in annual revenue. Where that crosses our costs depends on team size, which depends on funding — and that is a model we need to build.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §4.2, §5.3 Confidence: Low Missing Information: See Q#095 — no break-even analysis.

Question #115

Category: Market Difficulty: Medium Question: What market trends work in your favour?

Short Answer (10–20 seconds): Subscription growth, rising subscription fatigue, and the proven success of infrastructure layers like Stripe, Twilio and Cloudflare showing that merchants will happily rent capability rather than build it.

Expanded Answer (30–60 seconds): There is a fourth trend specific to our market: digital payment volumes in Sri Lanka are projected to reach US$8.56 billion by 2029, and the e-commerce market is already around US$2.65 billion. That means the payment rails we depend on are maturing at exactly the time we need them. Ten years ago this product would have been much harder to launch here.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §4.2, §6.2; Passyn_INSL2026_PitchDeck.pdf slide 6 Confidence: High Missing Information: —

Question #116

Category: Market Difficulty: Hard Question: What market trends work against you?

Short Answer (10–20 seconds): Bundling. Large platforms increasingly package many services into one subscription, which reduces the number of separate subscriptions a user faces — and therefore some of our demand.

Expanded Answer (30–60 seconds): Partly Missing Information — our documents do not analyse headwinds. In my judgement the real ones are: bundling reducing subscription count; large platforms building short-term access natively once the idea is proven; and payment providers moving up the stack into access management. None of these are documented risks in our materials, which is itself a gap. Our answer to all three is speed and merchant relationships in a market the giants do not prioritise.

Supporting Evidence: No supporting document — Passyn_INSL2026_Proposal.pdf §8.1 lists only adoption, cannibalisation and integration risks Confidence: Low Missing Information: Your risk section has no market or competitive headwinds. Add them — showing you know your own threats scores well under research depth.

---

8. COMPETITORS

Question #117

Category: Competitors Difficulty: Hard Question: Who are your direct competitors?

Short Answer (10–20 seconds): Status: Missing Information — our documents describe the competitive category but do not name a single specific company.

Expanded Answer (30–60 seconds): Status: Missing Information. What we can say is the category position: most existing tools focus on monthly and annual subscriptions, and subscription-management and paywall tools manage recurring billing rather than brand-safe short-term passes. Very few address controlled expiring access as dedicated infrastructure. But we have not done a named competitor analysis, and I would rather tell you that than invent a comparison.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §8.2; Passyn_Context.md — "Competitive Advantage" Confidence: Low Missing Information: This is a serious gap for a 25-mark "Innovation & Value Proposition" criterion. The INSL booklet explicitly lists "no distinction from existing solutions" as a common mistake to avoid. Name at least 3–5 real companies and state how you differ. Do this before 8 August.

Question #118

Category: Competitors Difficulty: Medium Question: Who are your indirect competitors?

Short Answer (10–20 seconds): Free trials, freemium tiers, student discounts, and the merchant's own in-house build. Also, honestly, piracy and account sharing — they are free alternatives to what we sell.

Expanded Answer (30–60 seconds): Every one of these is a way a merchant currently addresses the same problem. Free trials are the default answer and earn nothing. Freemium keeps users but does not monetise the occasional buyer. Discounts damage the brand. An in-house build works but costs far more than our fee. And piracy and account sharing are what users choose when the merchant offers nothing — which is why we frame them as leaks we convert into revenue.

Supporting Evidence: Passyn_Context.md — "Why Businesses Need Passyn" (five leaks); Passyn_INSL2026_Proposal.pdf §2.3 Confidence: Medium Missing Information: Not documented as a competitive analysis — this is constructed from your problem statement.

Question #119

Category: Competitors Difficulty: Hard Question: What stops Stripe from building this next quarter?

Short Answer (10–20 seconds): Nothing technically. But Stripe optimises for payment volume, not for protecting a merchant's subscription brand — and the pricing rule and merchant trust are the hard parts, not the code.

Expanded Answer (30–60 seconds): The engineering here is not the moat, and I would not claim it is. What is hard is the strategic layer: knowing that short-term access must cost more per day than monthly, that language must never say "cheap," and that merchants need to be verified before they sell access. That knowledge comes from working closely with merchants in this specific problem. Also, large payment companies focus on large markets first, which gives a regional player real room to establish itself.

Supporting Evidence: Passyn_Context.md — "The Most Important Strategic Principle", "Language Strategy"; Passyn_INSL2026_Proposal.pdf §3.3 Confidence: Medium Missing Information: No documented moat or defensibility analysis. Write one.

Question #120

Category: Competitors Difficulty: Medium Question: What is your competitive advantage?

Short Answer (10–20 seconds): Six things together: merchant-first, brand-safe, pricing-protected, API-driven, scalable, and working for both digital and physical businesses. No existing subscription tool offers that combination.

Expanded Answer (30–60 seconds): The one that matters most is pricing-protected. Anyone can build a day-pass feature. What makes us safe for a merchant to adopt is the rule that passes always cost more per day than the monthly plan, plus the positioning language that keeps them a premium category rather than a discount. That turns us from a threat into a risk-free addition — and that is a business insight, not a technical one.

Supporting Evidence: Passyn_Context.md — "Competitive Advantage"; Passyn_INSL2026_Proposal.pdf §3.3, §8.2 Confidence: High Missing Information: —

Question #121

Category: Competitors Difficulty: Hard Question: Why would a merchant choose you over building it in-house?

Short Answer (10–20 seconds): Because they get it working today with one API call instead of building an access engine, expiry logic, revocation, webhooks, settlements and a dashboard — and then maintaining all of it forever.

Expanded Answer (30–60 seconds): The cost people underestimate is maintenance, not the initial build. An in-house version needs someone on call when expiry breaks and a customer is locked out of something they paid for. It needs security review, payment reconciliation and reporting. We carry all of that, and we spread the cost across every merchant. It is the same reason almost nobody builds their own payment processing anymore.

Supporting Evidence: passyn/docs/ARCHITECTURE.md (full system scope); Passyn_API_Architecture_Guide.pdf §1.3 ("rent that expertise by the request") Confidence: High Missing Information: No cost comparison figures. A simple "in-house costs X engineer-months versus our fee" slide would be powerful.

Question #122

Category: Competitors Difficulty: Medium Question: What is your moat?

Short Answer (10–20 seconds): Three layers over time: pricing intelligence data no one else has, integration switching costs once we are inside a merchant's product, and merchant trust as the brand-safe option.

Expanded Answer (30–60 seconds): Right now, honestly, our moat is thin — we are early. It builds in this order. First, data: every pass sold teaches us what duration and price actually converts, which becomes advice no competitor can replicate without volume. Second, switching costs: once verification is embedded in a merchant's product and their settlements run through us, replacing us is a project. Third, trust: being known as the option that does not cannibalise subscriptions.

Supporting Evidence: Passyn_Context.md — "Analytics Layer", "Competitive Advantage"; passyn/docs/API.md (integration surface) Confidence: Medium Missing Information: Not documented anywhere. Add a defensibility section to your materials.

Question #123

Category: Competitors Difficulty: Medium Question: How is this different from a gift card or voucher platform?

Short Answer (10–20 seconds): A voucher is stored value — it represents money. A pass is a time-boxed permission that activates, expires and can be revoked. The engine is completely different.

Expanded Answer (30–60 seconds): A gift card asks "how much credit is left?" A pass asks "is this window still open right now?" That means a pass needs an activation moment, a computed expiry, usage counting, revocation and a state machine — none of which a voucher system has. It also means the merchant integration is different: they call us at the moment of access, not at the moment of payment.

Supporting Evidence: lib/access-engine.ts (state machine); prisma/schema.prisma (Access model); passyn/docs/ARCHITECTURE.md §2.4 Confidence: High Missing Information: —

Question #124

Category: Competitors Difficulty: Hard Question: What happens if a competitor undercuts your commission to zero?

Short Answer (10–20 seconds): Then we compete on trust and outcomes rather than price. Merchants adopt us because we protect their subscription revenue — a free tool that cannibalises them costs them far more than 5%.

Expanded Answer (30–60 seconds): Price is the weakest form of competition in infrastructure, because the switching cost and the risk of getting access control wrong dominate the fee. A merchant will not hand access management to whoever is cheapest — they will hand it to whoever they trust not to break their business. Our defence is the pricing rule, our merchant verification, and eventually our conversion data. If we ever have to win on price alone, we have already lost the positioning.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §3.3, §5.2; Passyn_Context.md — "The Most Important Strategic Principle" Confidence: Medium Missing Information: No competitive response plan documented.

Question #125

Category: Competitors Difficulty: Medium Question: Aren't you just reinventing the day pass, which gyms have had for decades?

Short Answer (10–20 seconds): Exactly — and that is our strongest proof. Day passes work brilliantly in the physical world. Digital businesses never built the infrastructure to do the same thing safely. We are that infrastructure.

Expanded Answer (30–60 seconds): Gyms figured this out long ago: some people want a year, some want a day, and you sell both. Cinemas sell single tickets, not just memberships. The behaviour is proven and normal. Digital subscription businesses skipped it, not because customers did not want it, but because doing it badly cannibalises your monthly plan and there was no safe way to do it well. That is the gap.

Supporting Evidence: Passyn_Context.md — "Expanded Vision Beyond Digital"; Passyn_INSL2026_Proposal.pdf §4.1 Confidence: High Missing Information: —

Question #126

Category: Competitors Difficulty: Medium Question: Why would a developer choose your API over a competitor's?

Short Answer (10–20 seconds): Because the integration is essentially one call, the response envelope is consistent, the spec is machine-readable, and there is an interactive playground and a zero-dependency typed SDK.

Expanded Answer (30–60 seconds): Developer experience is genuinely competitive advantage for infrastructure. Every response has the same four fields whether it succeeded or failed, so error handling is written once. Errors have specific codes with a details array naming bad fields. Rate-limit headers are always present so nobody has to guess. The OpenAPI spec means their tooling generates a client automatically. And they can test with their own key in the browser before writing any code.

Supporting Evidence: passyn/docs/API.md (envelope, error codes, rate-limit headers); app/developers/playground; packages/sdk; app/api/v1/openapi.json Confidence: High Missing Information: —

Question #127

Category: Competitors Difficulty: Hard Question: If this is such a good idea, what is the risk a large merchant just copies your pricing rule and does it themselves?

Short Answer (10–20 seconds): For a very large merchant that is a rational choice, and we do not fight it — we sell them white-label licensing so they get their own brand and we keep the revenue.

Expanded Answer (30–60 seconds): The pricing rule is an idea, and ideas cannot be protected. What can be protected is the position: being the neutral layer that every merchant uses, accumulating data across all of them about what durations and prices actually convert. A single large merchant copying the rule only learns about their own customers. We learn across the whole market. And for the ones big enough to build, white-label converts a competitor into a customer.

Supporting Evidence: Passyn_Context.md — "Revenue Model" (White-Label), "Analytics Layer" Confidence: Medium Missing Information: —

---

9. MARKETING

Question #128

Category: Marketing Difficulty: Hard Question: How will you acquire your first merchants?

Short Answer (10–20 seconds): Direct outreach. Our documented plan is structured merchant discovery interviews with local SaaS, e-learning and gym or coworking businesses, converting the best of those into three to five pilots.

Expanded Answer (30–60 seconds): For the first ten merchants there is no scalable channel and there should not be — we need conversations, not campaigns. Being in Sri Lanka means we can meet a gym owner or a tuition centre director in person, which is a real advantage for a first infrastructure product. The interviews serve double duty: they validate pricing and willingness to integrate, and they produce our first customers.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §6.2, §7.1 Confidence: Medium Missing Information: No go-to-market document exists — no target list, no outreach script, no conversion assumptions. This was on your requested document list and is genuinely absent.

Question #129

Category: Marketing Difficulty: Hard Question: What is your customer acquisition strategy at scale?

Short Answer (10–20 seconds): Status: Missing Information — beyond pilot outreach, no scaled acquisition strategy is documented.

Expanded Answer (30–60 seconds): Status: Missing Information. What our documents commit to is direct merchant discovery and three to five pilots. Beyond that there is no documented channel strategy, no content or SEO plan, no partnership programme and no paid acquisition plan. For an Idea Stage submission that is defensible, but it is a real gap under "Market Viability," which carries 25 marks.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §7.1 Confidence: Low Missing Information: Define at least three channels with a rough cost and conversion assumption for each.

Question #130

Category: Marketing Difficulty: Medium Question: What is your digital marketing plan?

Short Answer (10–20 seconds): Status: Missing Information — no digital marketing plan exists in the documents.

Expanded Answer (30–60 seconds): Status: Missing Information. What exists in the product rather than the plan: a public marketing site with pricing, features, about and blog pages, and a public documentation site. Those are the assets a content and SEO strategy would run on, but no strategy is written.

Supporting Evidence: passyn/apps/web/app/(landing)/ (pricing, features, about, blog); app/docs/ Confidence: Low Missing Information: Define target keywords, content themes, and which channel you believe reaches merchant decision-makers.

Question #131

Category: Marketing Difficulty: Medium Question: Do you have an SEO strategy?

Short Answer (10–20 seconds): Status: Missing Information — no SEO strategy is documented, though the product includes a blog and a full public docs site, which are the right foundations.

Expanded Answer (30–60 seconds): Status: Missing Information. The observation worth making is that for developer-facing infrastructure, documentation is usually the strongest organic channel — developers search for how to solve a problem and land on docs. Our docs site with API, SDK, webhooks and examples pages is well positioned for that, but we have not planned or measured it.

Supporting Evidence: app/(landing)/blog; app/docs/api, app/docs/sdk, app/docs/webhooks, app/docs/examples Confidence: Low Missing Information: —

Question #132

Category: Marketing Difficulty: Medium Question: How will you use social media?

Short Answer (10–20 seconds): Status: Missing Information — no social media strategy is documented.

Expanded Answer (30–60 seconds): Status: Missing Information. No channels, content plan or audience strategy appear in any document. For a B2B infrastructure product the relevant question is which platform reaches Sri Lankan merchant owners and developers, and that has not been researched.

Supporting Evidence: No supporting document Confidence: Low Missing Information: —

Question #133

Category: Marketing Difficulty: Medium Question: Do you have an affiliate or referral strategy?

Short Answer (10–20 seconds): Status: Missing Information — no affiliate or referral programme is documented or built.

Expanded Answer (30–60 seconds): Status: Missing Information. There is no referral mechanism in the product and no partner-commission model in the business documents. Worth noting that the API does allow a partner to register merchants programmatically, which is the technical foundation an agency or reseller channel would need — but no commercial programme exists around it.

Supporting Evidence: passyn/docs/API.md — POST /v1/merchants ("Registers a merchant (partner integrations)") Confidence: Low Missing Information: —

Question #134

Category: Marketing Difficulty: Medium Question: What partnerships would accelerate you?

Short Answer (10–20 seconds): Payment gateways, e-learning platform providers, gym management software, and web agencies who build for many merchants at once — each gives access to many merchants through one relationship.

Expanded Answer (30–60 seconds): Partly Missing Information — partnerships are named as a team role in our proposal but no specific partners or partnership strategy are documented. The logic that makes sense to us: one integration with a gym management platform reaches every gym using it. Local payment gateways are the other obvious one, since we need them anyway for the Sri Lankan market.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §1.2 (Market & Growth role includes Partnerships); Passyn_Context.md — "Payment Layer" (local payment gateways) Confidence: Low Missing Information: No named partners, no partnership strategy.

Question #135

Category: Marketing Difficulty: Medium Question: How do you market to developers versus business owners?

Short Answer (10–20 seconds): Completely differently. Developers want documentation, an SDK and a playground they can try in five minutes. Business owners want a revenue number and proof it will not hurt their subscriptions.

Expanded Answer (30–60 seconds): The product already reflects that split — we built a developer portal with keys, docs, a playground and SDKs, and a separate merchant experience with a visual pass builder and analytics. The messaging follows: to a developer, "verify access in one API call." To an owner, "earn revenue from users who currently pay you nothing, without touching your monthly plan." Our future notes even plan separate sites for each audience.

Supporting Evidence: passyn/README.md (four portals); app/developers/*; app/merchant/*; passyn/futureUpdate.txt (separate developer and merchant subdomains) Confidence: Medium Missing Information: No written messaging framework per audience.

Question #136

Category: Marketing Difficulty: Hard Question: What is the one sentence you use to open a merchant conversation?

Short Answer (10–20 seconds): "How many people look at your pricing page every month and leave without buying anything? We can turn some of those into revenue without changing your monthly plan."

Expanded Answer (30–60 seconds): It works because it starts with their data, not our product, and it names a loss they already feel but have never quantified. It also preempts their first objection — that this will hurt their subscriptions — inside the same sentence. This is our positioning translated into a sales opening; it is not written down in our documents.

Supporting Evidence: Constructed from Passyn_Context.md — "Hidden Market Opportunity", "The Most Important Strategic Principle" Confidence: Medium Missing Information: No sales script or messaging document exists. Write one — it takes 20 minutes and makes your GTM answer concrete.

Question #137

Category: Marketing Difficulty: Medium Question: How will merchants explain passes to their own customers?

Short Answer (10–20 seconds): Using our language rules. Never "cheap," "budget" or "discount." Always Access Pass, Flex Pass, Day Pass, Exam Pass, or Controlled Access Window.

Expanded Answer (30–60 seconds): This is part of the product, not an afterthought — the language protects the merchant's brand perception. If a pass is described as a cheap plan, existing subscribers start asking why they pay monthly. If it is described as a Project Pass for people who need short-term flexibility, it reads as a premium convenience product. We guide merchants on this during onboarding.

Supporting Evidence: Passyn_Context.md — "Language Strategy"; Passyn_INSL2026_Proposal.pdf §3.3 Confidence: High Missing Information: No merchant-facing brand guideline document exists yet.

---

10. SALES

Question #138

Category: Sales Difficulty: Medium Question: What is your sales strategy?

Short Answer (10–20 seconds): Founder-led direct sales for the first pilots — meeting merchants in person in Sri Lanka. Self-serve through the dashboard and API comes later, once the product is proven.

Expanded Answer (30–60 seconds): The product is already built for self-serve, with registration, onboarding and API keys all available without talking to us. But self-serve only works once merchants already know what the category is, and nobody knows what micro-access infrastructure is yet. So the first phase is deliberately high-touch: three to five pilots we work closely with, whose data becomes the proof that makes self-serve possible.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §6.2, §7.1; app/merchant/onboarding, app/developers/api-keys Confidence: Medium Missing Information: No documented sales process, pipeline stages or targets.

Question #139

Category: Sales Difficulty: Hard Question: What is your sales cycle length?

Short Answer (10–20 seconds): Status: Missing Information — we have not sold to a merchant yet, so we have no measured sales cycle.

Expanded Answer (30–60 seconds): Status: Missing Information. What I would expect, and what the pilots will tell us: a gym or tuition centre should be fast, because the owner decides alone and there is no integration work — they use the dashboard and scan QR codes. A SaaS company should be slower, because it needs a product decision plus engineering time. But those are expectations, not data.

Supporting Evidence: No supporting document Confidence: Low Missing Information: Measure this in the pilots. It directly determines your cost of acquisition.

Question #140

Category: Sales Difficulty: Medium Question: What is the biggest objection you expect from merchants?

Short Answer (10–20 seconds): "This will cannibalise my monthly subscriptions." It is our documented top risk, and the pricing rule is the direct answer to it.

Expanded Answer (30–60 seconds): Our own risk section names it: proving passes grow rather than cannibalise revenue. The answer has three parts. The pricing rule makes monthly mathematically the best value, so no rational subscriber downgrades. The language keeps passes a separate premium category rather than a discount. And the analytics let the merchant measure the effect themselves — if it were cannibalising, they would see it and could turn it off in one click.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §8.1; Passyn_Context.md — "Pricing Psychology"; prisma/schema.prisma (Pass.isActive toggle) Confidence: High Missing Information: —

Question #141

Category: Sales Difficulty: Medium Question: How do you convert a pilot merchant into a paying merchant?

Short Answer (10–20 seconds): By showing them the number. If the analytics prove passes brought in revenue they were not earning before, the decision makes itself.

Expanded Answer (30–60 seconds): That is why conversion uplift is one of our five key metrics. A pilot that ends with "here is Rs.X you earned this month from users who previously paid you nothing, and here is your subscriber count, unchanged" is a very short negotiation. The risk is a pilot that produces ambiguous data, which is why picking pilot merchants with enough traffic to generate a clear signal matters.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §6.3, §7.1; passyn/docs/API.md (/v1/analytics/merchant) Confidence: Medium Missing Information: No pilot success criteria are defined. Define what result makes a pilot a "yes."

Question #142

Category: Sales Difficulty: Medium Question: How do you keep merchants — what is your retention strategy?

Short Answer (10–20 seconds): Retention comes from being embedded and from the revenue being real. Once verification is inside their product and settlements run through us, and the revenue line is visible, leaving costs them money.

Expanded Answer (30–60 seconds): Partly Missing Information — no formal retention programme is documented. Structurally, three things work in our favour: integration switching cost, the analytics showing incremental revenue, and net revenue retention as a tracked metric. What we do not have is a defined customer success process — check-in cadence, health scoring, or an at-risk playbook.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §6.3 (net revenue retention as a metric) Confidence: Low Missing Information: No retention or customer success plan.

Question #143

Category: Sales Difficulty: Hard Question: What churn rate do you expect?

Short Answer (10–20 seconds): Status: Missing Information — no churn assumption or target exists in our documents.

Expanded Answer (30–60 seconds): Status: Missing Information. We track net revenue retention as a planned metric but have set no target and made no assumption. Any number I gave you now would be invented. What I can say is that infrastructure products with embedded integrations typically churn less than standalone tools, because removing them is engineering work rather than a cancellation click.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §6.3 Confidence: Low Missing Information: Required for any financial model. See Q#095.

Question #144

Category: Sales Difficulty: Medium Question: How do you handle customer support?

Short Answer (10–20 seconds): Today, directly by the founding team. The product includes transactional email and an admin portal for merchant and user management, but there is no support system or SLA yet.

Expanded Answer (30–60 seconds): Partly Missing Information. What exists: an admin portal where we can inspect merchants, users, passes and audit logs to diagnose a problem, transactional email through Resend, and merchant-visible webhook delivery logs so integrators can self-diagnose most issues. What does not exist: a ticketing system, defined response times, or documented support tiers. Our cost structure names merchant onboarding and support as a major cost, so it is recognised, just not designed.

Supporting Evidence: app/admin/*; lib/email/; app/merchant/webhooks; Passyn_INSL2026_Proposal.pdf §5.3 Confidence: Medium Missing Information: No support model, SLA or escalation path.

Question #145

Category: Sales Difficulty: Hard Question: A merchant's customer is locked out of a pass they paid for at 11pm. What happens?

Short Answer (10–20 seconds): Right now, the merchant contacts us and we investigate through the admin portal. There is no 24/7 support and no automated remediation — that is a genuine gap for a product on the critical path.

Expanded Answer (30–60 seconds): This is the right question to ask an access company, because when we fail, someone who paid cannot get in. Technically we are well placed to diagnose it: the audit log shows every revocation with actor and IP, the access record shows exact status, activation and expiry, and analytics show every verification attempt. But diagnosis is not the same as response. A defined support process with out-of-hours coverage is a launch requirement, not a nice-to-have, and we have not built it.

Supporting Evidence: lib/audit.ts; prisma/schema.prisma (Access status fields, AnalyticsEvent); absence of any support documentation Confidence: Medium Missing Information: No incident response or support process. Naming this proactively is much stronger than being caught by it.

Question #146

Category: Sales Difficulty: Medium Question: How do you price for a merchant who only sells ten passes a month?

Short Answer (10–20 seconds): The Starter tier with a low SaaS fee is designed for exactly that. The commission is small in absolute terms, so the low entry fee is what makes us worth adopting.

Expanded Answer (30–60 seconds): This is why we are hybrid rather than pure commission. Ten passes a month at 5% is negligible revenue for us but the merchant still costs us support and infrastructure. The low SaaS fee covers the cost to serve. And a small merchant is still valuable — they are proof, a reference, and they may grow. What we have not decided is the actual Starter price.

Supporting Evidence: prisma/schema.prisma (MerchantPlan.STARTER default); Passyn_INSL2026_Proposal.pdf §5.2 Confidence: Medium Missing Information: See Q#090.

Question #147

Category: Sales Difficulty: Hard Question: How many merchants have you signed so far?

Short Answer (10–20 seconds): None yet. We are at the concept-validation stage with a working prototype. Our immediate next step is structured discovery interviews and three to five pilot merchants.

Expanded Answer (30–60 seconds): I would rather be direct about that. What we have is a complete working platform and a clearly defined pilot plan across three segments — SaaS, education and physical access. What we do not have is a signed merchant or a paying customer. For the Idea Stage that is the expected position, and our documents say so plainly.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §6.1, §7.1; Passyn_INSL2026_PitchDeck.pdf slide 6 Confidence: High Missing Information: —

---

11. FINANCIALS

Read this before the section. Financials are your weakest documented area. There is no financial model, no cost figures, no funding ask and no break-even analysis anywhere in your documents. Under the live marking criteria, "Market Viability & Business Model" carries 25 marks and "Initial Monetization" is explicitly named. Building even a one-page model before 8 August is the highest-value work you can do.

Question #148

Category: Financials Difficulty: Medium Question: What are your revenue projections?

Short Answer (10–20 seconds): Our documented target is 300 to 500 merchants generating roughly US$0.4 to 0.6 million in annual recurring revenue within three years in Sri Lanka.

Expanded Answer (30–60 seconds): That is the only revenue projection in our materials, and it is presented as our obtainable market rather than as a year-by-year forecast. It comes from SaaS fees plus transaction commissions. Working backwards it implies about US$1,000 to 1,300 per merchant per year. We do not have a year-one, year-two, year-three breakdown, and I would rather say that than present a number I cannot defend.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §4.2; Passyn_INSL2026_PitchDeck.pdf slide 4 Confidence: Medium Missing Information: No year-by-year projection. Build a simple three-year table: merchants, average revenue per merchant, total revenue.

Question #149

Category: Financials Difficulty: Hard Question: What are your monthly costs right now?

Short Answer (10–20 seconds): Status: Missing Information — no cost figures exist in the documents. Currently we run on free development tiers with no funding and no salaries.

Expanded Answer (30–60 seconds): Status: Missing Information. What I can describe is the shape from our cost structure: cloud infrastructure, engineering, payment-gateway fees, merchant onboarding and support, and go-to-market. What I cannot give you is a number, because we have not costed it. Practically, our current burn is close to zero — we are students, unfunded, running on development tiers.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §5.3; passyn/docs/DEPLOYMENT.md (managed services, no cost figures) Confidence: Low Missing Information: Cost the deployment stack. Vercel, Railway Postgres and Redis, Stripe fees, Resend, and R2 all have public pricing. This is an afternoon's work and turns a "missing" into a real answer.

Question #150

Category: Financials Difficulty: Medium Question: What are your main variable costs?

Short Answer (10–20 seconds): Payment-gateway fees on every pass sold, plus incremental database and compute cost. Everything else — engineering, infrastructure baseline, support — is largely fixed.

Expanded Answer (30–60 seconds): The commercially important point is that gateway fees come out of the transaction, and our commission has to be set above them for the transaction to be profitable for us. That is a real constraint on how low our commission can go, and it is a reason to prefer local gateways in Sri Lanka where card fees on small rupee-denominated transactions can be proportionally heavy.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §5.3; Passyn_Context.md — "Payment Layer" (local payment gateways) Confidence: Medium Missing Information: No gateway fee percentage is documented. Look up Stripe's and a local gateway's rates and know the number.

Question #151

Category: Financials Difficulty: Hard Question: What are your gross margins?

Short Answer (10–20 seconds): We describe them as strong — as an API-first software platform the marginal cost per additional merchant or pass is very low — but we have not calculated an actual percentage.

Expanded Answer (30–60 seconds): Partly Missing Information. The qualitative claim in our proposal is that low marginal cost gives strong gross margins and operating leverage as we scale, which is structurally true for software. But margin percentage depends on the gateway fee against our commission, and we have not modelled that. On the SaaS fee portion, margins should be very high. On the commission portion, it depends entirely on where gateway fees land.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §5.3 Confidence: Low Missing Information: Calculate margin separately for the SaaS line and the commission line.

Question #152

Category: Financials Difficulty: Hard Question: When do you break even?

Short Answer (10–20 seconds): Status: Missing Information — no break-even analysis exists.

Expanded Answer (30–60 seconds): Status: Missing Information. We have a three-year revenue target but no cost model, so we cannot state a break-even point. What determines it is team size, which depends on funding. If we hired two engineers, our costs become mostly salary, and break-even is roughly the merchant count whose combined fees cover that. That is a calculation we need to do.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §4.2, §5.3 Confidence: Low Missing Information: High priority. Even a rough number — "we break even at roughly N merchants" — is a strong, memorable answer.

Question #153

Category: Financials Difficulty: Hard Question: How much funding are you asking for?

Short Answer (10–20 seconds): Status: Missing Information — no funding amount is stated anywhere in our documents.

Expanded Answer (30–60 seconds): Status: Missing Information. This is a significant gap. The INSL Idea Stage criteria include "Business & Funding Strategy — monetization model and clear use of funds," and the Business Stage criteria mention "a clear ask." Our documents describe the business model thoroughly but never state an amount or what it buys.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf (no funding section); INSL delegate booklet evaluation criteria Confidence: Low Missing Information: Decide an amount and a use-of-funds breakdown before 8 August. Given your stated need — hiring experienced engineers to harden an existing prototype — a small, specific ask tied to named hires and a runway period is far more credible than a large round.

Question #154

Category: Financials Difficulty: Hard Question: What would you spend investment on?

Short Answer (10–20 seconds): Primarily on experienced engineers to review, harden and complete the prototype. Then on pilot merchant acquisition, security review, and production infrastructure.

Expanded Answer (30–60 seconds): We are unusual in that our product mostly exists and our team is the gap, not the code. So the priority order is: hire senior engineering help to do a security review and build the missing operational layer — monitoring, CI, reconciliation, disaster recovery. Then legal review for handling merchant funds. Then a small budget for merchant acquisition during the pilot phase. That is an honest, specific use of funds, though it is not yet written down anywhere.

Supporting Evidence: Derived from documented gaps in passyn/docs/DEPLOYMENT.md and ARCHITECTURE.md; Passyn_INSL2026_Proposal.pdf §5.3 Confidence: Medium Missing Information: Not documented. Write this as a use-of-funds slide — it is one of your most credible answers.

Question #155

Category: Financials Difficulty: Medium Question: Have you raised any money?

Short Answer (10–20 seconds): No. We are entirely unfunded. Everything built so far was built by the five of us without external capital.

Expanded Answer (30–60 seconds): That is worth stating clearly because it changes how you read the prototype. A full four-portal platform with an API, database, payments and QR verification, built by five students with no funding — that is a capital-efficiency signal. It also explains the gaps honestly: things like a paid security audit or monitoring tooling cost money we have not had.

Supporting Evidence: No funding is mentioned in any document; Passyn_INSL2026_Proposal.pdf §6.1 Confidence: High Missing Information: —

Question #156

Category: Financials Difficulty: Medium Question: What is your runway?

Short Answer (10–20 seconds): We have no burn to speak of — no salaries and development-tier infrastructure — so runway is not currently our constraint. Time and engineering capacity are.

Expanded Answer (30–60 seconds): Partly Missing Information. Because we are students working without pay on free and low-cost tiers, we are not running out of money. What we are running out of is capacity: five people, none of them senior engineers, cannot harden a payments-adjacent platform and also do merchant discovery and also study. That constraint is what funding solves, not runway.

Supporting Evidence: No financial documents exist Confidence: Medium Missing Information: —

Question #157

Category: Financials Difficulty: Hard Question: What is your customer acquisition cost?

Short Answer (10–20 seconds): Status: Missing Information — we have acquired no merchants and spent nothing on acquisition, so we have no CAC.

Expanded Answer (30–60 seconds): Status: Missing Information. For the pilot phase our acquisition cost is founder time rather than money, which is not a number we can report. Once we have pilots, the meaningful figures will be how many conversations produce one merchant, and how long the sales cycle runs. Both come out of the pilot phase.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §7.1 Confidence: Low Missing Information: —

Question #158

Category: Financials Difficulty: Hard Question: What is the lifetime value of a merchant?

Short Answer (10–20 seconds): Status: Missing Information — we have no churn assumption, so we cannot calculate lifetime value.

Expanded Answer (30–60 seconds): Status: Missing Information. The inputs would be annual revenue per merchant, which our own targets imply at roughly US$1,000 to 1,300, and an average merchant lifetime, which we have not estimated. Without a churn figure any LTV number would be invented. What I would argue qualitatively is that embedded infrastructure churns less than standalone tools, so lifetime should be long — but that is reasoning, not data.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §4.2, §6.3 Confidence: Low Missing Information: See Q#143.

Question #159

Category: Financials Difficulty: Medium Question: How do you manage cash flow given you collect from users but pay merchants later?

Short Answer (10–20 seconds): We do not hold the funds — Stripe Connect routes money to merchants. Our revenue is the commission and the SaaS fee, so we are not exposed to a settlement float.

Expanded Answer (30–60 seconds): This is deliberate. If we collected pass revenue into our own account and paid merchants monthly, we would be sitting on other people's money, which creates both regulatory exposure and a temptation to spend float. Routing through Stripe Connect avoids both. Our database records the split for reporting and merchant visibility, but the money movement is the processor's responsibility.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §2.1 (Stripe Connect); prisma/schema.prisma (Settlement, Transaction.merchantShare/platformFee) Confidence: Medium Missing Information: No cash flow statement or working capital analysis exists.

Question #160

Category: Financials Difficulty: Hard Question: What financial metrics will you report to investors?

Short Answer (10–20 seconds): Merchants onboarded, gross pass volume, passes sold, net revenue retention, and pass-to-subscription conversion uplift — our five defined key metrics.

Expanded Answer (30–60 seconds): Gross pass volume is the headline for an infrastructure business because our revenue is a fixed share of it, so it is the cleanest measure of whether the platform is working. Net revenue retention shows whether merchants expand over time. And conversion uplift is the one that proves the thesis — that passes add revenue rather than replacing subscriptions. We have not set target values for any of them yet.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §6.3; Passyn_INSL2026_PitchDeck.pdf slide 6 Confidence: High Missing Information: No targets set.

---

12. SECURITY

Question #161

Category: Security Difficulty: Medium Question: How do you protect merchant and user data?

Short Answer (10–20 seconds): Layered controls: role-based access at three levels, hashed passwords and API secrets, validation on every input, parameterised database queries, security headers, and an audit log on every sensitive action.

Expanded Answer (30–60 seconds): Concretely: passwords and API-key secrets are bcrypt-hashed. Every input crosses a Zod schema. Prisma parameterises every query, so SQL injection is not a surface. React escapes output and we sanitise any user-supplied rich text. Content Security Policy, HSTS, X-Frame-Options and Referrer-Policy headers are set. And every sensitive action — key creation, merchant approval, access revocation, settings changes — is logged with the actor and IP address.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §6; passyn/README.md (security highlights); lib/audit.ts Confidence: High Missing Information: —

Question #162

Category: Security Difficulty: Medium Question: How is data encrypted?

Short Answer (10–20 seconds): In transit by HTTPS with HSTS enforced. Secrets are hashed rather than encrypted — passwords and API secrets with bcrypt, key lookups with SHA-256.

Expanded Answer (30–60 seconds): The distinction matters: passwords and API secrets are hashed one-way, so even we cannot read them — an API key is displayed exactly once at creation and can never be recovered. For encryption at rest of the database itself, we rely on the managed provider's default disk encryption. We have not implemented field-level encryption for any personal data, which would be worth reviewing for compliance.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §2.5, §6; passyn/docs/SETUP.md §4 (keys "stored hashed and cannot be recovered") Confidence: Medium Missing Information: Encryption at rest is assumed from the provider, not verified or documented. No field-level encryption of personal data.

Question #163

Category: Security Difficulty: Hard Question: How do you prevent someone forging access?

Short Answer (10–20 seconds): Access is a database record, not a token a user holds. Verification reads our database directly. The QR token is HMAC-signed, expires in five minutes and is compared in constant time.

Expanded Answer (30–60 seconds): For digital verification there is nothing to forge — the merchant asks us whether a user has valid access and we look it up. For physical verification, the QR token is signed with HMAC-SHA256 using a server secret, so it cannot be created without that secret. We compare signatures in constant time to prevent timing attacks. Any tampered, malformed or expired token returns the same generic failure message, so an attacker learns nothing from the error.

Supporting Evidence: lib/qr-token.ts (HMAC-SHA256, 300s expiry, crypto.timingSafeEqual, uniform failure reason); lib/access-engine.ts Confidence: High Missing Information: —

Question #164

Category: Security Difficulty: Medium Question: What happens if an API key leaks?

Short Answer (10–20 seconds): The merchant revokes it from the dashboard and it stops working immediately. Damage is bounded because keys are scoped, rate-limited and can carry an expiry.

Expanded Answer (30–60 seconds): Several controls limit the blast radius. Keys are scoped, so a read-only key cannot revoke access. They are rate-limited per key. They carry an optional expiry. They track last-used time, so unusual activity is visible. And revocation is audit-logged. Test keys and live keys are separate, so a leaked test key cannot touch real money. What we do not yet have is automated anomaly detection that would notice a leak before the merchant does.

Supporting Evidence: prisma/schema.prisma (ApiKey.permissions, rateLimit, expiresAt, revokedAt, lastUsedAt, mode); passyn/docs/API.md (revoked_key, expired_key) Confidence: High Missing Information: No automated anomaly or leak detection.

Question #165

Category: Security Difficulty: Hard Question: Have you had a security audit?

Short Answer (10–20 seconds): No. The architecture follows established practices and the sensitive logic is unit-tested, but no external security review has been done. That is a launch requirement, not an optional extra.

Expanded Answer (30–60 seconds): I want to be direct because this matters more for us than for most startups — we sit on the access path and we touch payments. We have designed defensively: three-layer RBAC, hashed secrets, signed webhooks, constant-time comparisons, audit logging, validation everywhere. But designing defensively and being verified secure are different things, and only an external review closes that gap. It is one of the first things funding should buy.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §6 (design); no audit documentation exists Confidence: High Missing Information: No external security audit or penetration test.

Question #166

Category: Security Difficulty: Medium Question: How do you protect against common web attacks?

Short Answer (10–20 seconds): SQL injection is closed by Prisma's parameterised queries. XSS by React escaping plus sanitisation of rich text. CSRF by NextAuth on auth routes and token authentication on the API. Plus security headers.

Expanded Answer (30–60 seconds): There is a nice property in the API design: because the public API is token-authenticated and uses no cookies, it has no CSRF surface at all — an attacker cannot make a victim's browser send an API key it does not have. Portal mutations use same-site POST with an origin check. Headers set Content Security Policy, HSTS, X-Frame-Options and Referrer-Policy. Rate limiting also blunts brute-force attempts, and auth endpoints are limited per IP.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §6 (CSRF, XSS, headers); lib/rate-limit.ts (per-IP for auth endpoints) Confidence: High Missing Information: —

Question #167

Category: Security Difficulty: Medium Question: How do you handle authentication security for user accounts?

Short Answer (10–20 seconds): Bcrypt-hashed passwords, JWT sessions, per-IP rate limiting on auth endpoints, and a password reset flow using single-use hashed tokens with an expiry.

Expanded Answer (30–60 seconds): The reset flow is worth detail: reset tokens are stored hashed with a unique index, carry an expiry and record when they were used, so a token cannot be replayed. Accounts also carry a status — active, pending, suspended or banned — and a suspended account's API keys stop working immediately with a specific error code. What we do not have is multi-factor authentication, which I would consider mandatory for admin and merchant accounts before launch.

Supporting Evidence: prisma/schema.prisma (PasswordResetToken with tokenHash unique, expiresAt, usedAt; UserStatus); passyn/docs/API.md (suspended_account); app/(auth)/forgot-password, reset-password Confidence: High Missing Information: No MFA. Name it as a launch requirement.

Question #168

Category: Security Difficulty: Hard Question: How do you know an admin has not abused their access?

Short Answer (10–20 seconds): Every admin action is audit-logged with the actor, the action, the resource, the IP address and a timestamp. Cross-tenant queries are the only admin-only paths and they are all logged.

Expanded Answer (30–60 seconds): The architectural decision that makes this work is that admin queries are the only cross-tenant paths in the system, and they are explicitly audit-logged. So there is a complete record of every time someone with platform access looked across merchants or changed something — merchant approvals and suspensions, key creation and revocation, access revocation, settings changes. The honest limit is that the audit log is inside the same system an admin controls; a tamper-evident external log would be stronger.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §2.3, §6; prisma/schema.prisma (AuditLog with userId, action, resource, ipAddress); app/admin/logs Confidence: High Missing Information: Audit log is not externally replicated or tamper-evident.

Question #169

Category: Security Difficulty: Medium Question: How do merchants verify that a webhook really came from you?

Short Answer (10–20 seconds): Every delivery carries an HMAC-SHA256 signature over the timestamp and body, in Stripe's format. Merchants verify with constant-time comparison and reject anything older than five minutes.

Expanded Answer (30–60 seconds): The timestamp inside the signed payload is what stops replay attacks — an attacker who captured a valid webhook cannot resend it later, because the timestamp will be stale. We tell merchants explicitly to reject anything older than five minutes and to make handlers idempotent on the event ID, so a duplicate delivery cannot double-apply. Our SDK ships a verification helper so integrators do not have to implement the comparison themselves and get it wrong.

Supporting Evidence: passyn/docs/API.md (webhook signature section); lib/webhooks.ts; tests/unit/webhooks.test.ts; packages/sdk (verifyWebhookSignature) Confidence: High Missing Information: —

Question #170

Category: Security Difficulty: Medium Question: What personal data do you actually store?

Short Answer (10–20 seconds): Name and email for users, a hashed password, and account status. For merchants, business details, website, country and optionally a city and location. No card data ever.

Expanded Answer (30–60 seconds): We deliberately hold very little. Card details never touch our systems — Stripe Checkout handles that, which is exactly why we chose it. We store a Stripe customer identifier rather than payment information. Beyond that it is transaction records, access records and analytics events which may carry a country code. Minimising what we hold is both a security decision and a compliance one.

Supporting Evidence: prisma/schema.prisma (User, Merchant, AnalyticsEvent.country, stripeCustomerId); passyn/docs/ARCHITECTURE.md §2.1 (Checkout keeps PCI burden with Stripe) Confidence: High Missing Information: No formal data inventory or classification document.

Question #171

Category: Security Difficulty: Hard Question: Are you compliant with data protection regulations?

Short Answer (10–20 seconds): Status: Missing Information — we have not done a compliance review against Sri Lanka's Personal Data Protection Act or GDPR.

Expanded Answer (30–60 seconds): Status: Missing Information. The architecture has properties that help — we store minimal personal data, no card data, everything is audit-logged, and data is tenant-isolated. But no compliance assessment has been done, no privacy policy or terms of service exist in our documents, and there is no data retention policy, deletion process or documented lawful basis for processing. For a platform handling transactions this needs legal input.

Supporting Evidence: No legal or compliance documents exist in the folder Confidence: Low Missing Information: Genuine gap. See Q#211–#215.

Question #172

Category: Security Difficulty: Medium Question: How do you keep secrets out of your code?

Short Answer (10–20 seconds): Everything is environment-variable driven and never committed. Our deployment guide states explicitly that auth, Stripe and Resend keys live only in the host's environment manager.

Expanded Answer (30–60 seconds): The post-deploy checklist includes verifying that secrets are only in the environment manager and never in the repository. Development uses an example environment file that is copied and filled locally. The authentication secret is generated fresh per environment. And because integrations degrade gracefully when keys are absent, a developer can work on most of the product without ever holding production secrets.

Supporting Evidence: passyn/docs/DEPLOYMENT.md §4, §6; passyn/docs/SETUP.md §3; .gitignore Confidence: High Missing Information: No secret rotation policy documented.

Question #173

Category: Security Difficulty: Hard Question: What is your worst-case security scenario and how bad would it be?

Short Answer (10–20 seconds): A compromised admin account. It could approve fake merchants and revoke access across tenants. Every action would be logged, but the log lives in the system the attacker controls.

Expanded Answer (30–60 seconds): Admin is the highest-value target because it is the only cross-tenant role. The mitigations that exist are hashed credentials, RBAC at three layers, and comprehensive audit logging with IP addresses. The mitigations that are missing are the ones that would actually stop it: multi-factor authentication on admin accounts, external replication of the audit log, and anomaly alerting. Those three are on my pre-launch list, and I would name them to any investor rather than wait to be asked.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §2.3, §6; absence of MFA and alerting Confidence: High Missing Information: —

---

13. OPERATIONS

Question #174

Category: Operations Difficulty: Easy Question: Who is on your team?

Short Answer (10–20 seconds): Five members — Dilrukshsn, Sara, Kirushaliny, Sahri and Krivashan — from Sabaragamuwa University, working under the Blansyn brand.

Expanded Answer (30–60 seconds): Partly Missing Information. The names are in the pitch deck, but the proposal's team roles section still contains bracketed placeholders rather than actual assignments. The suggested structure is founder and team leader for vision and product strategy, co-founder for technical architecture, a market and growth role, a product and UX role, and a finance and operations role.

Supporting Evidence: Passyn_INSL2026_PitchDeck.pdf slide 1; Passyn_INSL2026_Proposal.pdf §1.2 (placeholders not filled) Confidence: Medium Missing Information: Fill in the real roles. Judges score team background under "Startup Overview & Clarity." Also verify the university on record — your pitch deck says Sabaragamuwa (Zone C, 8 August) and the delegate booklet requires all members from the same university.

Question #175

Category: Operations Difficulty: Medium Question: Who does what on the team?

Short Answer (10–20 seconds): The intended split is founder and product strategy, technical architecture and API, market and growth, product and UX, and finance and operations — one person per area across five members.

Expanded Answer (30–60 seconds): Partly Missing Information. That structure is the one proposed in our documents but the names are not yet assigned to it in writing. Practically, this matters for the Q&A: the INSL booklet advises assigning team members to field specific questions on problem, market and funding strategy, and only one member delivers the pitch.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §1.2; INSL Delegate Booklet §8 ("Assign team members to field-specific Q&A questions") Confidence: Medium Missing Information: Assign names to roles, and assign who answers which type of question in the live Q&A.

Question #176

Category: Operations Difficulty: Hard Question: Nobody on your team is a senior engineer. How is that not fatal?

Short Answer (10–20 seconds): Because the hard part of this business is not the code — it is knowing that passes must cost more per day than monthly. We found that insight, and we can hire the engineering.

Expanded Answer (30–60 seconds): I would rather be honest than oversell. Our team is strong on product thinking and business strategy and light on deep engineering, and the prototype was built with AI assistance. But two things make that workable. First, the strategic insight — the pricing rule, the language rules, the merchant-first positioning — is what makes this defensible, and that is ours. Second, senior engineering is hireable, and hiring it is the specific thing we want funding for.

Supporting Evidence: Passyn_Context.md — "The Most Important Strategic Principle"; passyn/docs/ARCHITECTURE.md §2 (documented decisions); Passyn_INSL2026_Proposal.pdf §1.2 Confidence: High Missing Information: —

Question #177

Category: Operations Difficulty: Medium Question: Who would you hire first?

Short Answer (10–20 seconds): A senior backend or platform engineer to review the architecture, run a security pass, and build the missing operational layer — monitoring, CI, reconciliation and disaster recovery.

Expanded Answer (30–60 seconds): That role solves our biggest single risk, which is that a prototype touching payments and access goes live without experienced review. The second hire would be a merchant-facing person for onboarding and support, because our cost structure names that as a major cost and it does not scale with founders alone. This ordering is my judgement — it is not documented.

Supporting Evidence: Derived from documented gaps in passyn/docs/; Passyn_INSL2026_Proposal.pdf §5.3 Confidence: Medium Missing Information: No hiring plan exists. Write a three-role plan with rough salaries — it makes your funding ask concrete.

Question #178

Category: Operations Difficulty: Medium Question: Do you have advisors or mentors?

Short Answer (10–20 seconds): Status: Missing Information — no advisors are named in any document. INSL itself provides mentorship through the competition, which is one reason we entered.

Expanded Answer (30–60 seconds): Status: Missing Information. The competition offers mentorship with entrepreneurs, investors and domain specialists, and workshops that are mandatory for participants. But we have no independent advisory board, and for a team of students building payments-adjacent infrastructure, a technical advisor would materially reduce our risk.

Supporting Evidence: INSL Delegate Booklet §2 (mentorship opportunities); no advisor documentation Confidence: Low Missing Information: —

Question #179

Category: Operations Difficulty: Medium Question: How will you support merchants operationally?

Short Answer (10–20 seconds): Today, directly by the team, using the admin portal to diagnose issues. Merchants can self-serve on most integration problems through their webhook delivery logs and the developer playground.

Expanded Answer (30–60 seconds): Partly Missing Information. The self-service tooling is genuinely good — a merchant can see exactly which webhook deliveries failed, with response codes, and replay them. Developers can test calls in the playground before writing code. That removes a lot of support volume. What we lack is a support process, response-time commitments and out-of-hours coverage.

Supporting Evidence: app/merchant/webhooks; app/developers/playground; app/admin/*; Passyn_INSL2026_Proposal.pdf §5.3 Confidence: Medium Missing Information: See Q#144, Q#145.

Question #180

Category: Operations Difficulty: Medium Question: How do you approve merchants, and why does that matter?

Short Answer (10–20 seconds): Merchants start in a pending state and cannot sell until our admin team approves them. It matters because anyone selling access through us affects our reputation and our merchants' trust.

Expanded Answer (30–60 seconds): The approval step is a deliberate friction. We are asking merchants to trust us with their access control and their revenue, so we cannot allow anyone to sign up and start selling immediately. Approval and suspension are both audit-logged. What is not defined is the criteria — what we actually check before approving. That needs writing down before we take real merchants.

Supporting Evidence: prisma/schema.prisma (MerchantStatus.PENDING default); app/admin/merchants; lib/audit.ts Confidence: High Missing Information: No documented merchant verification criteria or KYC process.

Question #181

Category: Operations Difficulty: Medium Question: How do you maintain the platform once merchants depend on it?

Short Answer (10–20 seconds): Through migration discipline, a documented post-deploy checklist, and scheduled jobs for expiry webhooks and settlements. The gap is that none of it is automated in a CI pipeline yet.

Expanded Answer (30–60 seconds): The discipline that exists is real: schema changes ship as committed migrations applied before deploy, never as direct pushes. The post-deploy checklist verifies the API, authentication, Stripe webhooks, a full test purchase and security headers. Scheduled jobs handle prompt expiry notifications and the monthly settlement run. What is missing is automation — no CI running tests before a deploy, and no monitoring to tell us when something breaks.

Supporting Evidence: passyn/docs/DEPLOYMENT.md §5, §6, §7 Confidence: High Missing Information: No CI/CD, no monitoring. See Q#057, Q#058.

Question #182

Category: Operations Difficulty: Hard Question: You are all students. How do you handle exams and this business at once?

Short Answer (10–20 seconds): Honestly, it is a real constraint, and it is part of why we want to bring in engineering help rather than promise we can do everything ourselves.

Expanded Answer (30–60 seconds): Partly Missing Information — no operating plan is documented. What I would say to a judge is that the prototype existing at all proves we can deliver under that constraint. But scaling to real merchants with support obligations is a different commitment, and pretending five students with exams can run 24/7 support would be dishonest. That is precisely the resource gap our funding ask addresses.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §1.2 (student team); passyn/ codebase as delivered evidence Confidence: Medium Missing Information: No commitment or time-allocation plan documented.

Question #183

Category: Operations Difficulty: Medium Question: What tooling do you use to run the company?

Short Answer (10–20 seconds): For the product: a pnpm monorepo, Git, Prisma migrations, Vitest and Playwright for tests. Business operations tooling is not documented.

Expanded Answer (30–60 seconds): Partly Missing Information. The engineering side is well organised — a workspace containing the platform and the SDK, contribution guidelines covering code style, branching and pull request process, and a documented local setup that takes a fresh machine to a seeded running platform. Business operations — CRM, project management, accounting — are not documented at all, which is expected pre-revenue.

Supporting Evidence: passyn/pnpm-workspace.yaml; passyn/docs/CONTRIBUTING.md; passyn/docs/SETUP.md Confidence: Medium Missing Information: —

---

14. RISKS

Question #184

Category: Risks Difficulty: Medium Question: What are your biggest risks?

Short Answer (10–20 seconds): Three documented ones: merchant adoption speed, proving passes grow rather than cannibalise revenue, and integration complexity. The cannibalisation one is existential.

Expanded Answer (30–60 seconds): We mitigate all three the same way — with the protective pricing rule, a low-friction API, and a pilot-first, data-led rollout that proves incremental revenue before we scale. But I would add risks our documents do not list: no security audit, no production monitoring, an unproven local payment path, and a team without senior engineering. Those are execution risks rather than thesis risks, but they are real.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §8.1; documented gaps across passyn/docs/ Confidence: High Missing Information: Your documented risk list covers only three business risks. Expand it to include technical, legal and market risks.

Question #185

Category: Risks Difficulty: Hard Question: What is the single biggest risk that could kill this company?

Short Answer (10–20 seconds): That passes turn out to cannibalise subscriptions rather than add to them. Our whole promise to merchants depends on that being false, and it is not yet proven.

Expanded Answer (30–60 seconds): Every other risk has a workaround. If integration is hard, we simplify it. If adoption is slow, we sell harder. But if the pilot data shows that pass buyers are mostly people who would have subscribed monthly, then we are a cannibalisation tool and no merchant should adopt us. That is why the pilots are designed to measure exactly this, and why conversion uplift is our headline metric.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §8.1, §6.3, §7.1 Confidence: High Missing Information: No experimental design for how the pilots will isolate cannibalisation from incremental revenue. Worth thinking through — a control group or before-and-after comparison.

Question #186

Category: Risks Difficulty: Medium Question: What are your technical risks?

Short Answer (10–20 seconds): No external security audit, no production monitoring or alerting, no automated test gate, no payment reconciliation, and no disaster recovery plan. All operational rather than architectural.

Expanded Answer (30–60 seconds): The distinction matters. The architecture is sound — the access engine is tested, tenancy is enforced structurally, secrets are handled correctly. The risks are in the operational layer that turns a prototype into a service someone can depend on. That is normal for a prototype and it is fixable with experienced engineering, which is exactly what we would hire.

Supporting Evidence: passyn/tests/ scope; absence of monitoring, CI and DR sections in passyn/docs/DEPLOYMENT.md Confidence: High Missing Information: Not documented as risks anywhere in your business materials.

Question #187

Category: Risks Difficulty: Medium Question: What are your business risks?

Short Answer (10–20 seconds): Slow merchant adoption, difficulty proving incremental revenue, and integration complexity — plus a category nobody has heard of, which means every sale starts with education.

Expanded Answer (30–60 seconds): The category risk is one our documents do not name but I think is real. "Micro-access infrastructure" is not a term merchants search for. We are not competing for budget in an existing category; we are creating one. That makes the first ten merchants disproportionately hard and disproportionately important, because they become the proof that shortens every conversation after.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §8.1; Passyn_Context.md — "Competitive Advantage" Confidence: Medium Missing Information: Category creation risk is not documented.

Question #188

Category: Risks Difficulty: Hard Question: What is your dependency risk on Stripe?

Short Answer (10–20 seconds): Significant. Stripe is our only payment path and our settlement mechanism, and it is not fully available to merchants in every market including Sri Lanka.

Expanded Answer (30–60 seconds): Two separate exposures. Operationally, a Stripe outage stops new sales, though existing access keeps working because verification never touches Stripe. Strategically, the bigger issue is availability — our context document names local payment gateways as part of the payment layer, but that integration is not built. For a Sri Lanka launch, local gateway support is not optional, and I would treat it as a top priority alongside hardening.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §8; Passyn_Context.md — "Payment Layer"; lib/stripe.ts Confidence: High Missing Information: No local gateway is named, evaluated or integrated. This is a launch blocker for your own beachhead market.

Question #189

Category: Risks Difficulty: Hard Question: What legal risks do you face?

Short Answer (10–20 seconds): Handling merchant funds, data protection compliance, and merchant liability if access fails. None of these have had legal review.

Expanded Answer (30–60 seconds): Status: Missing Information on all three. On funds, using Stripe Connect should keep us out of money transmission territory but that has not been legally confirmed for Sri Lanka. On data, we have no privacy policy, terms of service or compliance assessment. On liability, if our system wrongly denies access to a paying customer, our exposure to the merchant is undefined because we have no terms. These need a lawyer, not a founder's opinion.

Supporting Evidence: No legal documents exist in the research folder Confidence: Low Missing Information: See Q#211–#219.

Question #190

Category: Risks Difficulty: Medium Question: What market risks do you face?

Short Answer (10–20 seconds): Bundling reducing the number of separate subscriptions, large platforms building this natively once proven, and payment providers moving up into access management.

Expanded Answer (30–60 seconds): Partly Missing Information — none of these appear in our documented risk section. Our answer to all three is the same: speed, focus on a market the giants deprioritise, and merchant relationships built by being physically present. Plus the white-label option, which turns the largest potential competitors into customers.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §8.1 (does not cover these); Passyn_Context.md — "Revenue Model" (White-Label) Confidence: Low Missing Information: Add market and competitive risks to your risk section.

Question #191

Category: Risks Difficulty: Medium Question: What financial risks do you face?

Short Answer (10–20 seconds): We have no financial model, so our biggest financial risk is that we do not yet know our own break-even point or unit economics.

Expanded Answer (30–60 seconds): Status: Missing Information. With no funding and no burn, we are not at risk of running out of money today. The risk is decision-making: without cost figures we could set a commission that does not cover gateway fees, or price a tier below cost to serve. Those are avoidable mistakes that only a model prevents, and we have not built one.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §5.3 (qualitative only) Confidence: Low Missing Information: See Q#149, Q#152.

Question #192

Category: Risks Difficulty: Hard Question: What is your key-person risk?

Short Answer (10–20 seconds): High. We are five students, the technical work is concentrated, and there is no documented succession or knowledge transfer.

Expanded Answer (30–60 seconds): Partly Missing Information. What mitigates it is documentation — the architecture, API, setup, deployment and contributing guides mean the system is explained rather than living only in someone's head, and there is a plain-language API guide written specifically so non-technical people can understand the technology. That genuinely reduces key-person risk. What is not addressed is what happens if a team member leaves after graduation, and the competition rules do not allow changing team members after registration.

Supporting Evidence: passyn/docs/ (five guides); Passyn_API_Architecture_Guide.pdf; INSL Delegate Booklet §9 Confidence: Medium Missing Information: —

Question #193

Category: Risks Difficulty: Medium Question: What happens if a merchant abuses your platform?

Short Answer (10–20 seconds): We can suspend or ban them. Merchant status supports pending, approved, suspended and banned, and a suspended account's API keys stop working immediately.

Expanded Answer (30–60 seconds): The controls are there and they are enforced at the API level — a suspended account gets a specific error code rather than silently failing. Suspension is audit-logged. What is not defined is policy: what counts as abuse, what warning process applies, and what happens to users who hold valid passes from a suspended merchant. That last one is a genuine unanswered question, because those users paid.

Supporting Evidence: prisma/schema.prisma (MerchantStatus, UserStatus); passyn/docs/API.md (suspended_account); app/admin/merchants Confidence: Medium Missing Information: No abuse policy, and no defined handling of active passes when a merchant is suspended.

Question #194

Category: Risks Difficulty: Hard Question: What if a merchant refunds a pass a user has already used?

Short Answer (10–20 seconds): The system handles refunds — transactions have a refunded status and we listen to Stripe's refund event. What is not defined is the business policy on partial use.

Expanded Answer (30–60 seconds): Technically, a transaction can be marked refunded with a timestamp, and our Stripe webhook subscribes to the charge refunded event. Access can be revoked separately with a reason, and that is audit-logged. So the mechanics exist. The policy does not: whether a user who used two days of a seven-day pass gets a full or partial refund, and who absorbs the commission, are business decisions we have not made.

Supporting Evidence: prisma/schema.prisma (TransactionStatus.REFUNDED, refundedAt); passyn/docs/DEPLOYMENT.md §2 (charge.refunded event); lib/access-engine.ts (revoke) Confidence: Medium Missing Information: No refund policy. Merchants will ask this in the first meeting.

Question #195

Category: Risks Difficulty: Hard Question: What if your system wrongly denies access to someone who paid?

Short Answer (10–20 seconds): It is the worst failure we can have. We can diagnose it precisely from the audit log and access record, but we have no defined remediation process or support coverage.

Expanded Answer (30–60 seconds): The diagnostic position is strong: the access record shows exact status, activation and expiry, analytics record every verification attempt, and revocations are logged with actor and IP. So we can always answer what happened and why. What is missing is the response — no support process, no out-of-hours coverage, no automated remediation, and no defined liability to the merchant. For a company on the access critical path those are launch requirements.

Supporting Evidence: lib/audit.ts, lib/analytics.ts; prisma/schema.prisma; absence of support documentation Confidence: Medium Missing Information: See Q#145, Q#189.

---

15. SCALING

Question #196

Category: Scaling Difficulty: Easy Question: How would you handle 1,000 users?

Short Answer (10–20 seconds): The current architecture handles that with no changes. A single application instance and one PostgreSQL database are comfortable at that scale.

Expanded Answer (30–60 seconds): At a thousand users the constraint is not technology, it is us — merchant onboarding, support and the manual approval step all take founder time. The system itself would barely notice. What we would want in place before that point is monitoring, so we can see problems rather than hear about them from a merchant.

Supporting Evidence: passyn/docs/DEPLOYMENT.md §7; passyn/docs/ARCHITECTURE.md §7 Confidence: Medium Missing Information: No load testing has been done, so this is architectural reasoning rather than measured capacity.

Question #197

Category: Scaling Difficulty: Medium Question: How would you handle 10,000 users?

Short Answer (10–20 seconds): Also fine architecturally. This is where Redis caching and connection pooling start earning their keep, and where monitoring stops being optional.

Expanded Answer (30–60 seconds): The app is stateless, so more instances is the answer on the compute side. The database is the constraint that appears first, and our documentation names connection pooling as the first knob because serverless platforms open many short-lived connections. Redis is already in place for rate limits and hot-read caching. Analytics rollups would need pre-computing rather than aggregating on every dashboard load.

Supporting Evidence: passyn/docs/DEPLOYMENT.md §7 ("Postgres pooling is the first knob, Redis is already in place"); ARCHITECTURE.md §7 Confidence: Medium Missing Information: No measured throughput figures.

Question #198

Category: Scaling Difficulty: Hard Question: How would you handle 100,000 users?

Short Answer (10–20 seconds): Read replicas for the database, pre-computed analytics rollups, and possibly extracting the verify endpoint into its own service so it scales independently of the portals.

Expanded Answer (30–60 seconds): At this scale the verification endpoint dominates traffic, because it is called on every access check while everything else is occasional. That is exactly why the architecture keeps business logic in library modules rather than route handlers — the API can be extracted into a standalone service without a rewrite. The analytics event table would also need partitioning or archiving, since it is append-only and grows with every action.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §1 ("could be extracted into a standalone service later"), §7; prisma/schema.prisma (AnalyticsEvent append-only with indexes) Confidence: Medium Missing Information: No documented scaling plan beyond pooling and Redis. This answer is architectural reasoning, not a written plan.

Question #199

Category: Scaling Difficulty: Hard Question: How would you handle 1 million users?

Short Answer (10–20 seconds): Status: Missing Information — no scalability plan exists at that scale. Structurally it would need multi-region deployment, database sharding by merchant, and a dedicated verification service.

Expanded Answer (30–60 seconds): Status: Missing Information. What I can say is that the architecture does not block it. Tenancy is already keyed on merchant ID, which is the natural sharding key. The application is stateless. The verification path is a single indexed lookup that caches well. But going from reasoning to a plan requires load testing and capacity modelling we have not done, and I would not want to give you numbers I have not measured.

Supporting Evidence: prisma/schema.prisma (merchant-keyed tenancy); passyn/docs/ARCHITECTURE.md §2.3 Confidence: Low Missing Information: No scalability plan document exists — this was on your requested list and is genuinely absent.

Question #200

Category: Scaling Difficulty: Medium Question: What breaks first as you grow?

Short Answer (10–20 seconds): Database connections, then analytics queries. Compute scales easily because the app is stateless; the database is the shared resource everything contends for.

Expanded Answer (30–60 seconds): Connection exhaustion is the classic serverless failure — many short-lived instances each opening connections until the database refuses more. That is why our deployment guide specifies the pooled connection URL and names PgBouncer as the first mitigation. After that, analytics: the event stream is append-only and grows forever, so dashboard queries aggregating over it get slower every month unless we pre-compute rollups.

Supporting Evidence: passyn/docs/DEPLOYMENT.md §1, §7; prisma/schema.prisma (AnalyticsEvent) Confidence: High Missing Information: —

Question #201

Category: Scaling Difficulty: Medium Question: How does your business scale, not just your technology?

Short Answer (10–20 seconds): Through self-serve onboarding and the API. A merchant can register, onboard through a wizard, create passes and get API keys without ever talking to us.

Expanded Answer (30–60 seconds): The parts that do not scale today are the manual merchant approval step and founder-led sales. Approval is a deliberate trust decision, so it should stay human but become fast and criteria-driven. Sales has to shift from founder conversations to inbound and partnerships — one integration with a gym management platform reaching many gyms is the model. That transition is not planned in our documents.

Supporting Evidence: app/merchant/onboarding; app/developers/api-keys; prisma/schema.prisma (MerchantStatus.PENDING) Confidence: Medium Missing Information: No documented plan for scaling go-to-market.

Question #202

Category: Scaling Difficulty: Hard Question: Does the pricing rule still work at scale, across thousands of merchants?

Short Answer (10–20 seconds): It works better at scale, because with volume we can tell merchants exactly which durations and price points convert — turning a rule into data-backed advice.

Expanded Answer (30–60 seconds): Right now the rule is a principle we explain during onboarding. With thousands of merchants and millions of passes, our analytics layer would know that in education, a seven-day pass at a certain multiple of the daily rate converts best, while in fitness a different shape wins. That is genuinely valuable and impossible to replicate without volume. It is also the strongest argument for our data moat.

Supporting Evidence: Passyn_Context.md — "Pricing Psychology", "Analytics Layer"; passyn/docs/API.md (/v1/analytics/merchant) Confidence: Medium Missing Information: No documented plan to productise pricing intelligence.

Question #203

Category: Scaling Difficulty: Medium Question: How do you scale into a new country?

Short Answer (10–20 seconds): Mainly by adding local payment gateways and currency support. The access engine and API are country-agnostic — nothing about the core product is Sri Lanka specific.

Expanded Answer (30–60 seconds): The data model already carries currency on passes and transactions, and merchants carry a country. Multi-currency support is named in our future update notes. The real work per country is payments — each market has its preferred local gateways — plus compliance review and local merchant relationships. So expansion is a distribution and payments problem, not an engineering rewrite, which is what makes regional scaling realistic.

Supporting Evidence: prisma/schema.prisma (Pass.currency, Merchant.country); passyn/futureUpdate.txt; Passyn_INSL2026_Proposal.pdf §8.3 Confidence: Medium Missing Information: No country-by-country expansion sequence or compliance checklist.

---

16. AI

Question #204

Category: AI Difficulty: Medium Question: Do you use AI in your product?

Short Answer (10–20 seconds): No. There is no AI feature in the product today. We used AI to help build it, but the platform itself contains no machine learning or AI functionality.

Expanded Answer (30–60 seconds): I want to be clear about that distinction because a lot of startups blur it. Passyn is deterministic infrastructure — an access engine, an API, a payment flow. There is no model making decisions about access, and there should not be: when someone has paid for access, whether they get in must be a rule, not a prediction. AI-generated pricing suggestions would be a future feature, not core functionality.

Supporting Evidence: passyn/apps/web/lib/ (no AI or ML modules); passyn/docs/ARCHITECTURE.md (no AI in stack) Confidence: High Missing Information: —

Question #205

Category: AI Difficulty: Medium Question: But your parent company mentions AI systems. How does that connect?

Short Answer (10–20 seconds): Blansyn's stated vision includes AI systems among the infrastructure it wants to build. Passyn is the access infrastructure product, not the AI one.

Expanded Answer (30–60 seconds): Blansyn aims to create scalable technology platforms, APIs, AI systems and digital infrastructure. Passyn is the first product under that umbrella and it addresses access, not AI. Where the two could meet later is in our analytics layer — pricing and conversion intelligence is the natural place for a model, because we would have real data to train on. But that is a future product decision, not something we claim today.

Supporting Evidence: Passyn_Context.md — "Parent Company"; Passyn_INSL2026_Proposal.pdf §1.1 Confidence: High Missing Information: —

Question #206

Category: AI Difficulty: Hard Question: You used AI to build the product. Is that a strength or a weakness?

Short Answer (10–20 seconds): Both, and I will not pretend otherwise. It let five students with no funding produce a complete platform. It does not replace experienced review, which is why we want to hire engineers.

Expanded Answer (30–60 seconds): The honest accounting is this. Strength: capital efficiency. A full four-portal platform with a versioned API, database schema, payments, QR verification and documentation — built by a student team with no money. That would have been impossible five years ago. Weakness: AI does not give you operational judgement. It did not tell us to add monitoring, or to reconcile lost payment webhooks, or to get a security audit. Those gaps are real and we know exactly what they are.

Supporting Evidence: passyn/ codebase scope; passyn/docs/ARCHITECTURE.md §2 (documented decisions); documented operational gaps Confidence: High Missing Information: —

Question #207

Category: AI Difficulty: Medium Question: Where would AI genuinely add value to Passyn later?

Short Answer (10–20 seconds): In pricing intelligence — recommending the pass duration and price most likely to convert for a given merchant, based on patterns across the whole platform.

Expanded Answer (30–60 seconds): That is the one place where we would have a data advantage nobody else has: which durations and prices actually convert, by segment. A second candidate is fraud and sharing detection — spotting patterns of access abuse across merchants. Both need volume first. Neither is built, and neither is documented as a plan; this is my judgement of where the value would be.

Supporting Evidence: Passyn_Context.md — "Analytics Layer"; prisma/schema.prisma (AnalyticsEvent stream) Confidence: Medium Missing Information: No AI roadmap is documented.

Question #208

Category: AI Difficulty: Hard Question: What are the limitations of AI for your kind of product?

Short Answer (10–20 seconds): Access decisions must be deterministic and auditable. Nobody who paid should be denied entry because a model was uncertain. AI belongs in advice, not in the access path.

Expanded Answer (30–60 seconds): Our access engine is a state machine with clear rules, and when it says no it gives a specific reason like "access has expired." That explainability is a feature — a merchant can always answer their customer. A probabilistic system on the critical path would break that. So the design principle is that AI can suggest what to price or flag what looks suspicious, but the decision to open the door stays a rule.

Supporting Evidence: lib/access-engine.ts (deterministic resolveStatus, canUse with reasons); passyn/docs/API.md (human-readable failure reasons) Confidence: High Missing Information: —

Question #209

Category: AI Difficulty: Medium Question: How do you respond to a judge who says "this is just an AI-generated project"?

Short Answer (10–20 seconds): The code was AI-assisted. The insight was not. The pricing rule, the brand-safety positioning and the merchant-first model came from understanding the problem, and that is what makes this a business.

Expanded Answer (30–60 seconds): I would say: ask me why we chose a monolith, why expiry settles lazily instead of using a cron job, why API keys carry two different hashes, or why passes must cost more per day than the monthly plan. Every one of those has a reason and I can explain it. AI wrote code faster than we could. It did not decide what to build or why merchants would trust it.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §2 (decisions with documented rationale and deviations); Passyn_Context.md — strategic principles Confidence: High Missing Information: —

Question #210

Category: AI Difficulty: Medium Question: Will AI make your business easier or harder over the next few years?

Short Answer (10–20 seconds): Easier to build, harder to defend. Anyone can now build features quickly, which means the moat has to be merchant trust, data and distribution — not code.

Expanded Answer (30–60 seconds): Not documented — this is my reasoning. If a competitor can build a comparable platform in weeks, then our advantage cannot be the software. It has to be the things AI cannot generate: relationships with merchants who trust us with their access, accumulated data on what pricing converts, and being embedded in their systems. That is actually a useful discipline — it forces us to compete on the right things.

Supporting Evidence: No supporting document Confidence: Low Missing Information: —

---

17. LEGAL

Section warning. There are no legal or compliance documents at all in your research folder. Every answer here is either Missing Information or reasoning from the technical design. Judges from an angel network will notice.

Question #211

Category: Legal Difficulty: Medium Question: Do you have terms of service?

Short Answer (10–20 seconds): Status: Missing Information — no terms of service exist.

Expanded Answer (30–60 seconds): Status: Missing Information. No terms of service, merchant agreement or acceptable use policy exists in our documents. For a platform where merchants sell to their own customers through our system, we need at minimum a merchant agreement defining our obligations, our liability limits, and what happens to active passes if a merchant leaves or is suspended.

Supporting Evidence: No legal documents in the research folder Confidence: Low Missing Information: Draft a merchant agreement and terms of service before onboarding any real merchant.

Question #212

Category: Legal Difficulty: Medium Question: Do you have a privacy policy?

Short Answer (10–20 seconds): Status: Missing Information — no privacy policy exists, though we do store very little personal data and no card data at all.

Expanded Answer (30–60 seconds): Status: Missing Information. What we can say factually is what we hold: name, email, hashed password and account status for users; business details for merchants; transaction and access records; and analytics events that may include a country code. Card data never touches our systems because Stripe Checkout handles it. That minimalism makes a privacy policy easier to write, but it does not substitute for one.

Supporting Evidence: prisma/schema.prisma (data model); passyn/docs/ARCHITECTURE.md §2.1 Confidence: Low Missing Information: —

Question #213

Category: Legal Difficulty: Hard Question: What regulations apply to you in Sri Lanka?

Short Answer (10–20 seconds): Status: Missing Information — no regulatory analysis has been done. The relevant areas are data protection, payment and money-handling rules, and consumer protection on refunds.

Expanded Answer (30–60 seconds): Status: Missing Information. I can name the areas but not the answers. Data protection because we hold personal data on Sri Lankan users. Payments and money handling because value flows through us to merchants, even though Stripe Connect is designed to keep us out of money transmission. Consumer protection because passes are prepaid access with expiry, which touches refund and fair-terms rules. Each needs professional advice.

Supporting Evidence: No regulatory documentation exists Confidence: Low Missing Information: Get a legal opinion on all three areas. This is a concrete, credible use of early funding.

Question #214

Category: Legal Difficulty: Medium Question: Do you own the intellectual property?

Short Answer (10–20 seconds): Status: Missing Information — no IP assignment, founder agreement or trademark registration is documented.

Expanded Answer (30–60 seconds): Status: Missing Information. The code sits in a repository under the Blansyn brand, and the documentation carries a Blansyn copyright notice. But there is no documented founder agreement assigning IP from individual team members to the company, no evidence Blansyn is a registered entity, and no trademark filing for Passyn or Blansyn. For a five-person student team this is the most common and most damaging gap, because it becomes very hard to fix after a disagreement.

Supporting Evidence: passyn/README.md ("© Blansyn"); no legal entity or IP documentation Confidence: Low Missing Information: Highest-priority legal item. A simple founders' agreement with IP assignment and equity split protects everyone.

Question #215

Category: Legal Difficulty: Hard Question: How long do you keep user data, and can a user delete it?

Short Answer (10–20 seconds): Status: Missing Information — no data retention policy and no user deletion process exist.

Expanded Answer (30–60 seconds): Status: Missing Information. Technically the database uses cascading deletes, so removing a user would remove their access records, transactions and audit trail. But that creates a conflict we have not resolved: financial and audit records generally must be retained, while a user has a right to deletion. Reconciling those requires a policy — typically anonymising the user while preserving the transaction record — and we have not designed it.

Supporting Evidence: prisma/schema.prisma (onDelete: Cascade on user relations, onDelete: SetNull on audit logs) Confidence: Low Missing Information: Define a retention policy and an anonymisation-based deletion process.

Question #216

Category: Legal Difficulty: Hard Question: Are you a payments company? Do you need a licence?

Short Answer (10–20 seconds): We designed specifically to avoid that. Funds route through Stripe Connect rather than through a Passyn account, so we are a software platform, not a money handler. But that has not been legally confirmed.

Expanded Answer (30–60 seconds): The architectural intent is clear: we never hold merchant funds. Stripe Connect exists so platforms can route money to merchants without becoming money transmitters, and our database records the split purely for reporting. That said, regulatory treatment varies by country and I would not want to assert compliance without a legal opinion, especially for Sri Lanka where we plan to launch and where Stripe availability itself is a question.

Supporting Evidence: passyn/docs/ARCHITECTURE.md §2.1 (Stripe Connect); prisma/schema.prisma (Settlement, stripeAccountId) Confidence: Medium Missing Information: See Q#213. Also relates to the unbuilt local gateway path — Q#188.

Question #217

Category: Legal Difficulty: Medium Question: Who is liable if a user cannot access what they paid for?

Short Answer (10–20 seconds): Status: Missing Information — with no terms of service, liability between us, the merchant and the end user is undefined.

Expanded Answer (30–60 seconds): Status: Missing Information. The commercially sensible structure is that the merchant owns the relationship with their customer, and our obligation runs to the merchant under a service agreement with defined limits. But none of that is written, which means today the position is simply undefined. For a company on the access critical path, this is not something to leave open.

Supporting Evidence: No terms or agreements exist Confidence: Low Missing Information: —

Question #218

Category: Legal Difficulty: Medium Question: What open-source licences are you using and are you compliant?

Short Answer (10–20 seconds): Status: Missing Information — no licence audit has been done, though the stack is standard permissively-licensed open source.

Expanded Answer (30–60 seconds): Status: Missing Information. The stack is mainstream — Next.js, Prisma, Tailwind, Zod, Recharts, Three.js, ioredis — which are typically permissive licences that pose no commercial problem. The shadcn-style components are vendored into our codebase, which is their intended consumption model. But we have not run a dependency licence audit, and for a commercial product that should be done.

Supporting Evidence: passyn/package.json, apps/web/package.json; passyn/docs/ARCHITECTURE.md §2.1 (vendored components) Confidence: Low Missing Information: —

Question #219

Category: Legal Difficulty: Hard Question: Is your company legally registered?

Short Answer (10–20 seconds): Status: Missing Information — the documents describe Blansyn as the parent company and technology venture, but no registration details appear anywhere.

Expanded Answer (30–60 seconds): Status: Missing Information. Our documents consistently present Blansyn as a technology-infrastructure venture with Passyn as its flagship product, and use a Blansyn copyright notice. But no company number, incorporation date or jurisdiction is recorded. A judge or investor will ask, and "we are in the process" is a fine answer if it is true — but you must know which it is.

Supporting Evidence: Passyn_Context.md — "Parent Company"; passyn/README.md ("© Blansyn") Confidence: Low Missing Information: Confirm the answer before 8 August.

---

18. INVESTORS

Question #220

Category: Investors Difficulty: Hard Question: How much are you raising and at what valuation?

Short Answer (10–20 seconds): Status: Missing Information — neither a funding amount nor a valuation appears in any of our documents.

Expanded Answer (30–60 seconds): Status: Missing Information. This is the most commonly asked investor question and we currently have no documented answer. Given our actual position — a working prototype, no revenue, no funding, and a team that needs senior engineering — a small, specific pre-seed ask tied to named hires and a defined runway would be far more credible than a large round or a valuation claim we cannot justify.

Supporting Evidence: No funding documentation exists Confidence: Low Missing Information: Decide the number before 8 August. The Idea Stage criteria explicitly include "clear use of funds."

Question #221

Category: Investors Difficulty: Hard Question: How would you justify your valuation?

Short Answer (10–20 seconds): Status: Missing Information — no valuation work has been done, and with no revenue and no merchants there is no defensible basis for one.

Expanded Answer (30–60 seconds): Status: Missing Information. Honestly, at this stage a valuation would be negotiated rather than calculated. What we would put on our side of that conversation is a working platform built without capital, a clear insight the market has not addressed, and a defined pilot plan. What we cannot put forward is revenue, merchants or measured traction.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §6.1 Confidence: Low Missing Information: —

Question #222

Category: Investors Difficulty: Medium Question: What milestones would the funding get you to?

Short Answer (10–20 seconds): A production-hardened platform with security review and monitoring, three to five pilot merchants live, and validated data on whether passes add revenue or cannibalise it.

Expanded Answer (30–60 seconds): Those three milestones are the ones that matter, because together they answer the only question that decides whether this company works. The technical milestone makes us safe to trust. The pilot milestone gives us customers. The data milestone proves the thesis. After those, the next raise is a completely different conversation because it would be backed by evidence rather than argument.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §7.1; documented technical gaps Confidence: Medium Missing Information: No milestone plan with dates or budget is documented. Attach months and rough costs.

Question #223

Category: Investors Difficulty: Medium Question: What is your growth strategy?

Short Answer (10–20 seconds): Prove it with pilots in Sri Lanka, expand across South Asia and emerging markets, broaden from digital into physical access businesses, then add white-label and enterprise offerings.

Expanded Answer (30–60 seconds): The sequencing matters. Pilots first, because without proof the category does not exist for merchants. Then geographic expansion, which is mainly a payments and distribution problem rather than an engineering one. Then vertical expansion into physical businesses, which our QR verification already supports. Then upmarket into white-label and enterprise, which is how revenue per customer grows without needing proportionally more customers.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §7.1, §7.2, §8.3; Passyn_Context.md — "Future Roadmap" Confidence: High Missing Information: No timeline or resource plan per stage.

Question #224

Category: Investors Difficulty: Hard Question: What is your exit strategy?

Short Answer (10–20 seconds): Status: Missing Information — no exit strategy is discussed in any document.

Expanded Answer (30–60 seconds): Status: Missing Information. The natural acquirers for access infrastructure would be payment platforms, subscription-management companies, or large regional software groups — the same logic by which infrastructure companies are usually bought by the platforms whose stack they extend. But that is reasoning, not a documented strategy, and I would rather say so than present speculation as a plan.

Supporting Evidence: No exit documentation exists Confidence: Low Missing Information: Some investors ask this at every stage. Prepare a two-sentence answer.

Question #225

Category: Investors Difficulty: Medium Question: Why should an investor back you rather than wait for traction?

Short Answer (10–20 seconds): Because the thing money buys right now — senior engineering to harden a platform that already exists — is exactly what unlocks the traction. Waiting means waiting for something the funding causes.

Expanded Answer (30–60 seconds): We are in an unusual position: the product mostly exists but cannot responsibly go live, because we lack the engineering experience to harden a system that touches payments and access. That is a bottleneck money removes directly. An investor entering now is not funding a concept, they are funding the last step between a working prototype and live merchants.

Supporting Evidence: passyn/ codebase; documented operational gaps; Passyn_INSL2026_Proposal.pdf §7.1 Confidence: Medium Missing Information: Not documented — constructed from your position.

Question #226

Category: Investors Difficulty: Hard Question: What traction can you actually show today?

Short Answer (10–20 seconds): No merchants, no revenue, no users. What we can show is a complete working platform, a documented architecture, and a defined pilot plan across three segments.

Expanded Answer (30–60 seconds): I would rather be exact than optimistic. Traction in the commercial sense is zero — we are at concept-validation stage by our own documents. What exists is build progress: four role-based portals, twenty-four API endpoints, a full database schema, Stripe payments with webhooks, QR verification, unit tests on the core logic, and a public documentation site. For an Idea Stage team, that is well ahead of the category, but it is not customer traction and I will not call it that.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §6.1; passyn/ codebase; Passyn_INSL2026_PitchDeck.pdf slide 6 Confidence: High Missing Information: —

Question #227

Category: Investors Difficulty: Medium Question: What validation do you have that this will work?

Short Answer (10–20 seconds): Three observable signals: rising subscription fatigue, the universal merchant problems of account sharing and piracy, and the proven success of infrastructure layers like Stripe and Twilio.

Expanded Answer (30–60 seconds): Those are market signals rather than customer validation, and I want to be clear about the difference. We have not yet run merchant interviews — that is our stated next step. So what we have is a well-reasoned thesis supported by observable market behaviour, not confirmed demand. Turning signal into validation through structured discovery is the immediate priority.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §6.2; Passyn_INSL2026_PitchDeck.pdf slide 6 Confidence: Medium Missing Information: No primary customer validation exists. This is your most important pre-pitch task. See the Final Review.

Question #228

Category: Investors Difficulty: Hard Question: What would you do with no funding at all?

Short Answer (10–20 seconds): Run the merchant discovery interviews, launch one pilot with a low-risk merchant such as a gym, and prove the thesis with real data before spending anything.

Expanded Answer (30–60 seconds): A gym or tuition centre is the right first pilot without funding, because it needs no engineering integration — they use the dashboard and scan QR codes. That gives us real pass sales, real revenue data and a reference customer at almost no cost. It does not solve the hardening problem, so we could not take a SaaS merchant with real traffic. But it would produce the evidence that makes funding much easier to raise.

Supporting Evidence: app/merchant/verify, lib/qr-token.ts (no-integration path); Passyn_INSL2026_Proposal.pdf §7.1 Confidence: Medium Missing Information: Not documented — constructed reasoning.

Question #229

Category: Investors Difficulty: Medium Question: How does the parent company structure affect investment?

Short Answer (10–20 seconds): Status: Missing Information — the relationship between Blansyn and Passyn is described strategically but never defined legally or financially.

Expanded Answer (30–60 seconds): Status: Missing Information. Our documents say Blansyn is the parent company building infrastructure products, and Passyn is its first flagship product. What is undefined is whether an investor would be investing in Blansyn or in Passyn as a separate entity, how IP is held, and what happens to Passyn if Blansyn builds other products. Investors care about this a great deal, and it needs deciding.

Supporting Evidence: Passyn_Context.md — "Parent Company"; Passyn_INSL2026_Proposal.pdf §1.1 Confidence: Low Missing Information: Clarify the entity structure before any investment conversation.

Question #230

Category: Investors Difficulty: Hard Question: What is the biggest thing you would want an investor to check before deciding?

Short Answer (10–20 seconds): Whether merchants actually want this. Talk to three subscription businesses and ask if they would sell a day pass at a premium per-day price. If they say no, our thesis is wrong.

Expanded Answer (30–60 seconds): I would rather point an investor at our weakest assumption than our strongest slide. Everything else — the technology, the market size, the pricing logic — follows from merchants wanting this. If merchants say they are happy losing that segment, or that they fear brand damage regardless of pricing, then the thesis fails and no amount of engineering fixes it. That is exactly what our pilot phase is designed to test.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §6.2, §8.1 Confidence: High Missing Information: —

Question #231

Category: Investors Difficulty: Medium Question: What do you want from INSL beyond prize money?

Short Answer (10–20 seconds): Mentorship and merchant introductions. Our biggest gaps are senior technical guidance and access to businesses willing to run a pilot — the competition offers both.

Expanded Answer (30–60 seconds): The competition explicitly provides mentorship with entrepreneurs, investors and domain specialists, workshops, and national exposure with access to stakeholders and collaborations. For us the mentorship matters more than the money, because our constraint is experience and relationships rather than cash. An introduction to three merchants willing to pilot would be worth more to us than the equivalent in funding.

Supporting Evidence: INSL Delegate Booklet §2 (why participate); Passyn_INSL2026_Proposal.pdf §7.1 Confidence: High Missing Information: —

---

19. JUDGES' DIFFICULT QUESTIONS

These are designed to be uncomfortable. Rehearse the ones marked CRITICAL until the answer is automatic.

Question #232

Category: Judges' Difficult Questions Difficulty: Hard — CRITICAL Question: You have no customers, no revenue and no validation. What exactly am I evaluating?

Short Answer (10–20 seconds): A clearly defined problem, a working platform that proves we can execute, and a specific insight — the pricing rule — that makes this safe for merchants to adopt. Not traction. We are not claiming traction.

Expanded Answer (30–60 seconds): You are evaluating three things. First, whether the problem is real: subscription businesses lose revenue to non-converting users, and no tool addresses it safely. Second, whether this team can execute: five students with no funding built a complete four-portal platform with a working API. Third, whether the insight is right: that passes must cost more per day than monthly to be safe. If you believe those three, the customers follow. If you do not believe the third, none of the rest matters.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §6.1; passyn/ codebase; Passyn_Context.md — "Pricing Psychology" Confidence: High Missing Information: —

Question #233

Category: Judges' Difficult Questions Difficulty: Hard — CRITICAL Question: Name one merchant who told you they want this.

Short Answer (10–20 seconds): None yet. We have not done merchant interviews. It is our documented next step and I will not invent a quote.

Expanded Answer (30–60 seconds): That is our biggest gap and I would rather name it than dress it up. Our proposal states plainly that the next step is structured merchant discovery interviews with local SaaS, e-learning and gym or coworking businesses. We built the product first, which in hindsight is the wrong order for validation even though it proved our execution. Fixing it is the first thing on our list.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §6.2 Confidence: High Missing Information: If you can complete even three merchant conversations before 8 August, this answer transforms. Highest-return action available to you.

Question #234

Category: Judges' Difficult Questions Difficulty: Hard — CRITICAL Question: Your proposal says pre-MVP. Now you say you have a platform. Which is it, and why should I trust either?

Short Answer (10–20 seconds): The proposal was written at concept stage. We built the prototype after submitting. Both statements were true when made — and I would rather explain the sequence than hide the code.

Expanded Answer (30–60 seconds): We registered as Idea Stage and our documents reflect where we were then. Since submission we built a working prototype using AI-assisted development. It is genuinely functional — four portals, a versioned API, payments, QR verification — and genuinely not production-ready, with no monitoring, no security audit and incomplete test coverage. So: further along than the paperwork, not as far along as a launch. That is the accurate answer.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §6.1; passyn/docs/ (dated June–July 2026); codebase Confidence: High Missing Information: —

Question #235

Category: Judges' Difficult Questions Difficulty: Hard — CRITICAL Question: What do you charge? Give me a number, not a model.

Short Answer (10–20 seconds): The commission is 5% per pass. The monthly tier prices are not yet set — we want pilot data before fixing them, and I would rather tell you that than make up a number.

Expanded Answer (30–60 seconds): What is decided: a hybrid of a low entry SaaS fee plus a transaction commission, with three tiers — Starter, Growth and Enterprise — and a 5% default commission set per merchant. What is not decided is the monthly price of each tier. Our reasoning is that we would be guessing at what a Sri Lankan merchant will pay, and the pilots will tell us. But I accept that not having the number is a weakness.

Supporting Evidence: prisma/schema.prisma (commissionBps @default(500), MerchantPlan); Passyn_INSL2026_Proposal.pdf §5.2 Confidence: Medium Missing Information: Set provisional tier prices before 8 August. See Q#090.

Question #236

Category: Judges' Difficult Questions Difficulty: Hard Question: Convince me in thirty seconds that this does not cannibalise subscriptions.

Short Answer (10–20 seconds): Because it costs more. A thousand-rupee monthly plan is thirty-three rupees a day. Our day pass is seventy-nine to a hundred and forty-nine. No subscriber downgrades to pay four times as much per day.

Expanded Answer (30–60 seconds): The maths does the work. Monthly is always the best value per day, by design, and that is enforced as the core product rule rather than left to the merchant's judgement. Then the language reinforces it — never cheap, budget or discount, always Access Pass or Project Pass, so it reads as a premium convenience product rather than a downgrade. And the merchant can measure it themselves in our analytics and switch it off in one click if they see anything they do not like.

Supporting Evidence: Passyn_Context.md — "Pricing Psychology", "Language Strategy"; Passyn_INSL2026_Proposal.pdf §3.3; prisma/schema.prisma (Pass.isActive) Confidence: High Missing Information: Note honestly that the rule is policy, not yet software-enforced. See Q#034.

Question #237

Category: Judges' Difficult Questions Difficulty: Hard Question: Your market numbers have no sources. Where did they come from?

Short Answer (10–20 seconds): The subscription and SaaS figures are published market forecasts. The Sri Lankan business count is our own estimate. I should be able to cite each one and currently I cannot.

Expanded Answer (30–60 seconds): Being precise about which is which: the US$650 billion to US$1.2 trillion subscription figures and the SaaS growth from US$408 to US$819 billion are industry forecasts. The Sri Lankan internet user, e-commerce and digital payment figures are published national statistics. The 8,000 to 10,000 access-based businesses and the US$25 to 30 billion South Asian figure are our own estimates. Presenting estimates and published figures in the same list without distinguishing them was a mistake in our deck.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §4.2 (no citations present) Confidence: Medium Missing Information: Add sources to your market slide, and label your own estimates as estimates. Judges from an angel network check this.

Question #238

Category: Judges' Difficult Questions Difficulty: Hard Question: Why are you competing in Idea Stage if you have a product?

Short Answer (10–20 seconds): Because we registered before we built it, and the rules do not allow changing category after registration. Our concept was the submission; the prototype came afterwards.

Expanded Answer (30–60 seconds): The competition guidelines state that participants select a category at registration and changes are not permitted. We registered as Idea Stage honestly, based on where we were. Building the prototype afterwards does not change that commitment, and I would not want to be seen gaming the category. What it does mean is that you are evaluating an Idea Stage team that can also show you working software.

Supporting Evidence: INSL Delegate Booklet §9 (category changes not permitted), §6.1; Passyn_INSL2026_Proposal.pdf §6.1 Confidence: High Missing Information: —

Question #239

Category: Judges' Difficult Questions Difficulty: Hard Question: How is this different from what already exists? Be specific.

Short Answer (10–20 seconds): Existing tools manage recurring billing. We manage expiring access — activation, expiry, revocation and usage limits — with a pricing rule that protects the merchant's monthly plan.

Expanded Answer (30–60 seconds): The difference is what the system is actually for. A billing tool answers "should we charge this customer this month?" We answer "is this person's access window open right now?" Those need completely different engines — a state machine, lazy expiry settlement, usage counting, revocation, signed webhooks. And the strategic layer on top, the rule that a pass must cost more per day than monthly, exists in no billing product because billing products are not trying to protect a brand from self-cannibalisation.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §8.2; lib/access-engine.ts; Passyn_Context.md — "Competitive Advantage" Confidence: Medium Missing Information: You cannot name a specific competitor. The INSL booklet lists "no distinction from existing solutions" as a top mistake. See Q#117.

Question #240

Category: Judges' Difficult Questions Difficulty: Hard Question: What happens when Spotify or Netflix says no?

Short Answer (10–20 seconds): They are not our customers. We sell to small and mid-sized businesses in Sri Lanka — SaaS startups, e-learning platforms, gyms and coworking spaces — where the decision-maker is one person.

Expanded Answer (30–60 seconds): The large platforms appear in our materials as examples of the subscription economy, not as target customers. A company that size builds its own infrastructure. Our documented market is 8,000 to 10,000 access-based businesses in Sri Lanka, and our beachhead is exactly the segment that cannot build this and cannot afford to lose the revenue.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §4.1, §4.2; Passyn_Context.md — "Target Customers (B2B)" Confidence: High Missing Information: —

Question #241

Category: Judges' Difficult Questions Difficulty: Hard Question: Your team has no senior engineer and no business experience. Why will you not fail on execution?

Short Answer (10–20 seconds): We might — execution risk is real. What reduces it is that we have already executed once under worse conditions, and that we know precisely which capability we lack.

Expanded Answer (30–60 seconds): The evidence against pure execution risk is the prototype: no funding, five students, and a complete platform with documented architectural decisions. That is not nothing. The honest counterweight is that shipping a prototype and running production infrastructure for paying merchants are different skills, and we do not have the second one. Teams fail when they do not know what they are missing. We can name ours: senior engineering, operational experience, and merchant relationships.

Supporting Evidence: passyn/ codebase and docs/; Passyn_INSL2026_Proposal.pdf §1.2 Confidence: High Missing Information: —

Question #242

Category: Judges' Difficult Questions Difficulty: Hard Question: What is your break-even point?

Short Answer (10–20 seconds): We have not calculated it. We have a three-year revenue target of US$0.4 to 0.6 million from 300 to 500 merchants, but no cost model to set against it.

Expanded Answer (30–60 seconds): I would rather admit the gap than produce a number I cannot defend under follow-up. What I can give you is the revenue side: roughly US$1,000 to 1,300 per merchant per year, so every hundred merchants is around US$100,000 to 130,000. Where that crosses our costs depends on team size, which depends on funding. Building that model is on our immediate list.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §4.2, §5.3 Confidence: Low Missing Information: Build the model. See Q#152.

Question #243

Category: Judges' Difficult Questions Difficulty: Hard Question: Walk me through your worst assumption.

Short Answer (10–20 seconds): That merchants will believe passes are incremental rather than cannibalising. We are confident in the logic, but we have zero evidence from an actual merchant.

Expanded Answer (30–60 seconds): Every part of our model rests on that. The pricing rule makes it mathematically sound. But merchants make decisions on fear as much as maths, and a subscription business protecting its core revenue may refuse regardless of the numbers. If merchants say "we understand the logic and we still will not risk it," we have a demand problem no engineering solves. That is the assumption I would test first, and it is exactly what pilots are for.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §8.1; Passyn_Context.md — "The Most Important Strategic Principle" Confidence: High Missing Information: —

Question #244

Category: Judges' Difficult Questions Difficulty: Hard Question: Why should we advance you over a team with paying customers?

Short Answer (10–20 seconds): You should not, if you are scoring traction. But this is the Idea Stage, where the criteria are problem identification, innovation and future potential — and we are strong on all three with working software behind them.

Expanded Answer (30–60 seconds): The Idea Stage evaluation focus is explicitly problem identification, innovation and creativity, and feasibility and future potential. We have a precisely defined problem, an innovation that is strategic rather than merely technical, and a functioning platform proving feasibility. If the question is who has more revenue today, we lose. If it is who has found a real gap and shown they can build into it, we compete well.

Supporting Evidence: INSL Delegate Booklet §6.1 (Idea Stage evaluation focus), §6 (live marking criteria) Confidence: High Missing Information: —

Question #245

Category: Judges' Difficult Questions Difficulty: Hard Question: You describe five revenue streams before earning one rupee. Isn't that unfocused?

Short Answer (10–20 seconds): Fair. Only two matter now — the SaaS fee and the commission. The other three are how the model grows later, not what we are building today.

Expanded Answer (30–60 seconds): I would accept the criticism of how we presented it. Enterprise plans, white-label licensing and premium analytics are all natural extensions of the same platform, and listing them shows the model has room to grow. But they are not a plan for the next two years, and presenting five streams equally suggests we would chase all of them. In practice: low SaaS fee plus 5% commission, and nothing else until we have merchants.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §5.1, §5.2; Passyn_INSL2026_PitchDeck.pdf slide 5 Confidence: High Missing Information: —

Question #246

Category: Judges' Difficult Questions Difficulty: Hard Question: Your product both serves merchants and lets users discover nearby merchants. Are you infrastructure or a marketplace?

Short Answer (10–20 seconds): Infrastructure. The discovery features exist because physical merchants need them, but merchants keep their brand, customers and pricing — we never own the customer relationship.

Expanded Answer (30–60 seconds): This is a sharp observation and I will not dodge it. The build does include merchant categories and a nearby-merchant lookup, which are marketplace-shaped features. The reason is physical access: a gym day pass is useless if a user cannot find the gym. But our stated philosophy is explicit — not a marketplace, not a reseller, not a discount platform — and that is a real strategic commitment, because the moment we compete with merchants for the customer, they stop trusting us with their access.

Supporting Evidence: Passyn_Context.md — "Key Philosophy"; lib/categories.ts; app/api/app/merchants/nearby; passyn/README.md Confidence: Medium Missing Information: The tension is real and undocumented. Decide your position clearly before someone forces it.

Question #247

Category: Judges' Difficult Questions Difficulty: Hard Question: Stripe is not fully available in Sri Lanka. How do you launch in your own beachhead market?

Short Answer (10–20 seconds): Local payment gateways, which our documents name as part of the payment layer but which we have not built. That is a genuine launch blocker and I would not pretend otherwise.

Expanded Answer (30–60 seconds): Our context document specifies card payments, wallet payments, local payment gateways and future global integrations. Only the Stripe path is built. For a Sri Lanka launch, local gateway integration is not optional and I would put it at the same priority as security hardening. The architecture supports it — payment logic is isolated in its own module — but the integration work has not been done and no local provider has been evaluated.

Supporting Evidence: Passyn_Context.md — "Payment Layer"; lib/stripe.ts, lib/checkout.ts; no local gateway code Confidence: High Missing Information: Name a candidate local gateway before 8 August. "We haven't looked into it" is much weaker than "we have identified X as our first integration."

Question #248

Category: Judges' Difficult Questions Difficulty: Hard Question: If I gave you nothing today, would this still exist in a year?

Short Answer (10–20 seconds): Yes, in a smaller form. We would run merchant interviews, launch one gym or tuition pilot that needs no integration, and prove the thesis with real data at almost no cost.

Expanded Answer (30–60 seconds): The platform is built and runs on development tiers, so our survival does not depend on funding. What funding changes is speed and scope — without it we cannot take a SaaS merchant with real traffic, because we cannot responsibly run unhardened infrastructure at scale. But we can absolutely prove whether merchants want this, and that is the question that matters most.

Supporting Evidence: passyn/docs/SETUP.md (runs locally with only a database); app/merchant/verify (no-integration path) Confidence: Medium Missing Information: —

Question #249

Category: Judges' Difficult Questions Difficulty: Hard Question: What question were you hoping I would not ask?

Short Answer (10–20 seconds): Whether any merchant has told us they want this. The answer is no, and it is the gap we most need to close.

Expanded Answer (30–60 seconds): We built the product before validating demand, which proved we could execute but got the order wrong. Everything else I can defend — the architecture with reasons, the pricing logic, the market shape. But the thesis rests on merchant demand and we have market signals rather than merchant confirmation. Structured discovery interviews are our documented next step, and they should have been our first one.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §6.2 Confidence: High Missing Information: —

---

20. UNEXPECTED QUESTIONS

Question #250

Category: Unexpected Difficulty: Hard Question: What does the name Passyn mean?

Short Answer (10–20 seconds): Status: Missing Information — no explanation of the name appears in any document. It clearly derives from "pass," consistent with the product.

Expanded Answer (30–60 seconds): Status: Missing Information. Neither Passyn nor Blansyn has a documented origin or meaning. Judges often ask this because it is a small window into how deliberate a founder is. Prepare a one-line answer — it costs nothing and a hesitation here reads badly.

Supporting Evidence: No supporting document Confidence: Low Missing Information: —

Question #251

Category: Unexpected Difficulty: Hard Question: Sell me a day pass right now. I am a gym owner.

Short Answer (10–20 seconds): You already sell day passes. You just track them on paper. We give you the same thing with online payment, a QR code at the door, automatic expiry, and a record of every visit.

Expanded Answer (30–60 seconds): Nothing about how you run your gym changes. A visitor buys a day pass on their phone before they arrive, so you take payment without handling cash. They show a QR code, your staff scans it, and the code expires in five minutes so it cannot be passed around outside. At the end of the month you see exactly how many day visitors you had and what they were worth — data you have never had before. And your monthly memberships stay untouched, because a day pass costs more per day than a membership does.

Supporting Evidence: lib/qr-token.ts; app/merchant/verify; lib/categories.ts (FITNESS); Passyn_Context.md — "Pricing Psychology", "Expanded Vision Beyond Digital" Confidence: High Missing Information: —

Question #252

Category: Unexpected Difficulty: Hard Question: Explain your product to my grandmother.

Short Answer (10–20 seconds): You know how a gym lets you pay for one day instead of joining for a year? We help internet businesses do the same thing — sell one day instead of one month.

Expanded Answer (30–60 seconds): Most apps and websites only let you pay monthly, even if you only need them for a few days. So people who need them briefly just do not buy at all, and the business earns nothing. We are the system underneath that lets those businesses sell a day, or a week. When the time is over, the door closes automatically — nobody has to remember to switch it off.

Supporting Evidence: Passyn_API_Architecture_Guide.pdf (plain-language framing); Passyn_Context.md Confidence: High Missing Information: —

Question #253

Category: Unexpected Difficulty: Hard Question: What is the most common mistake teams make in this competition, and did you make it?

Short Answer (10–20 seconds): The booklet lists insufficient validation and no distinction from existing solutions. We made both — we have no merchant interviews and we do not name specific competitors.

Expanded Answer (30–60 seconds): The listed mistakes are vague problem statements, no defined target audience, no distinction from existing solutions, text-heavy presentations, and insufficient validation. Our problem statement and audience are sharp. Our weaknesses are exactly the other two: no named competitor comparison and no primary validation. Naming that honestly is better than hoping you do not notice.

Supporting Evidence: INSL Delegate Booklet §11 (common mistakes); Passyn_INSL2026_Proposal.pdf §6.2, §8.2 Confidence: High Missing Information: —

Question #254

Category: Unexpected Difficulty: Hard Question: If a merchant tells you your pricing rule is wrong for their business, what do you do?

Short Answer (10–20 seconds): Listen carefully, because they know their customers better than we do. But the rule is what makes us safe, so I would want to understand their reasoning before bending it.

Expanded Answer (30–60 seconds): The rule exists to protect them, not us — so if a merchant tells us it does not fit, that is important data about a case we have not thought through. Some businesses may genuinely have seasonal or promotional needs where a lower rate makes sense. What I would not do is quietly allow it for everyone, because a merchant who cannibalises their own subscriptions through us blames us, and that damages every other merchant's trust.

Supporting Evidence: Passyn_Context.md — "Pricing Psychology", "The Most Important Strategic Principle" Confidence: Medium Missing Information: No exception policy documented.

Question #255

Category: Unexpected Difficulty: Hard Question: What is the smallest version of this business that still works?

Short Answer (10–20 seconds): Twenty gyms and tuition centres in Colombo selling day passes through the dashboard with QR verification. No API, no integration, no engineering — just the product working.

Expanded Answer (30–60 seconds): That version needs nothing we do not already have. It generates real revenue, real pass data and real merchant references. It also tests the thesis in the segment with the least integration friction. It is not a venture-scale business, but it is a real one, and everything larger is built on the same engine. If I had to choose one path with no funding, that is it.

Supporting Evidence: app/merchant/verify, lib/qr-token.ts; lib/categories.ts (FITNESS, EDUCATION); Passyn_Context.md — "Expanded Vision Beyond Digital" Confidence: Medium Missing Information: Not documented — constructed reasoning.

Question #256

Category: Unexpected Difficulty: Hard Question: Who is your biggest fan and who is your biggest sceptic?

Short Answer (10–20 seconds): Our biggest fans should be small merchants losing revenue they can see. Our biggest sceptics are subscription businesses afraid of touching their core revenue model.

Expanded Answer (30–60 seconds): Not documented — this is reasoning. A gym owner instantly understands a day pass; there is nothing to explain. A SaaS company with a carefully tuned subscription funnel has more to lose and will move slowly, which is why the pricing rule and their ability to switch it off in one click matter so much. Interestingly, the sceptics are the more valuable customers — which means our sales approach has to lead with safety, not opportunity.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §8.1; Passyn_Context.md — "The Most Important Strategic Principle" Confidence: Low Missing Information: No customer conversations have happened to confirm this.

Question #257

Category: Unexpected Difficulty: Hard Question: What would a competitor say is your biggest weakness?

Short Answer (10–20 seconds): That we are five students with no customers, no funding, no security audit, and an AI-built prototype. All of that is true.

Expanded Answer (30–60 seconds): A competitor would say we have no proof anyone wants this, no engineering depth, no operational track record, and a product nobody has stress-tested. Each of those is accurate today. What they could not say is that the problem is not real, that the pricing insight is wrong, or that we cannot build — because the platform exists. So the attack is entirely on execution and evidence, which are the things funding and pilots directly address.

Supporting Evidence: Documented gaps throughout passyn/docs/ and Passyn_INSL2026_Proposal.pdf §6.1 Confidence: High Missing Information: —

Question #258

Category: Unexpected Difficulty: Hard Question: Your product has categories for cinema, anime and streaming. Was that the original plan?

Short Answer (10–20 seconds): Those categories reflect where short-term access demand is most obvious to consumers — a single film, a weekend of a series. The strategy is unchanged; the categories are just how merchants are classified.

Expanded Answer (30–60 seconds): The system classifies merchants into watch providers, cinema, anime, live TV and OTT, fitness, education and other. That set does lean toward entertainment more than our business documents suggest, which mostly emphasise SaaS and education. It is worth being aware of that mismatch: a judge comparing your deck to your product could ask which is the real target market. My honest read is that the categories were chosen for demonstration realism, not as a strategy change — but you should confirm that yourself.

Supporting Evidence: lib/categories.ts; prisma/schema.prisma (MerchantCategory); compare with Passyn_INSL2026_Proposal.pdf §4.1 Confidence: Medium Missing Information: Genuine inconsistency between product and business documents. Decide which is the intended market and align them.

Question #259

Category: Unexpected Difficulty: Hard Question: What have you learned that surprised you?

Short Answer (10–20 seconds): That the hardest part was not building the access system — it was realising that a cheap day pass would destroy the merchant's business, and that pricing higher is what makes it safe.

Expanded Answer (30–60 seconds): The intuitive version of this idea is "make it cheaper for people who cannot afford a month." That version is dangerous — it cannibalises subscriptions and merchants would be right to reject it. Understanding that flexibility is worth a premium, and that monthly must always remain the best value, turned the idea from something no merchant would touch into something they can adopt with no risk. That inversion is the whole company.

Supporting Evidence: Passyn_Context.md — "The Big Insight", "Pricing Psychology", "The Most Important Strategic Principle" Confidence: High Missing Information: —

Question #260

Category: Unexpected Difficulty: Hard Question: If we gave you the top prize, what is the first thing you would do on Monday?

Short Answer (10–20 seconds): Book merchant interviews. Not hire, not build — talk to ten businesses and find out whether they want this. Everything else depends on that answer.

Expanded Answer (30–60 seconds): It is tempting to say hire an engineer, and that would come second. But we already have more product than validation, and spending money to build more before knowing merchants want it would repeat the mistake we already made. Ten conversations, three pilots, then hire to serve them properly. That sequence is the one I would defend to any investor.

Supporting Evidence: Passyn_INSL2026_Proposal.pdf §6.2, §7.1 Confidence: High Missing Information: —

Question #261

Category: Unexpected Difficulty: Hard Question: What is one thing in your pitch deck you would change?

Short Answer (10–20 seconds): The progress slide. It says concept-validation ahead of MVP, which understates what we have — and the market slide, which presents estimates and published forecasts as though they were the same thing.

Expanded Answer (30–60 seconds): Those are the two honest edits. The progress slide should show that a working platform exists while being clear it is not production-ready. The market slide should label which figures are published forecasts and which are our own estimates. Both changes make us more credible rather than less, because judges trust founders who distinguish what they know from what they assume.

Supporting Evidence: Passyn_INSL2026_PitchDeck.pdf slides 4 & 6; Passyn_INSL2026_Proposal.pdf §4.2, §6.1 Confidence: High Missing Information: —

Question #262

Category: Unexpected Difficulty: Hard Question: Why should we believe you will still be working on this in two years?

Short Answer (10–20 seconds): Because we built a complete platform with no money and no obligation to. Nobody does that for a class assignment.

Expanded Answer (30–60 seconds): Partly reasoning rather than documented. The evidence is the work itself — four portals, a versioned API, a documented architecture, a plain-language guide written so non-technical people could understand the technology, and a parent brand built around a long-term infrastructure vision. That is not the shape of a competition entry. The honest uncertainty is that we are students and graduation will force real choices, and I cannot pretend otherwise.

Supporting Evidence: passyn/ codebase and docs/; Passyn_API_Architecture_Guide.pdf; Passyn_Context.md — "Parent Company" Confidence: Medium Missing Information: No documented team commitment plan.

---

FINAL REVIEW

1. Weak Areas In Your Documents

Ranked by how much damage each will do in a live Q&A.

Tier 1 — Fix before 8 August

#	Weakness	Why it hurts	Marking criterion at risk
1	No customer discovery whatsoever. No merchant interviews, no user surveys, no willingness-to-pay data.	"Customer Discovery" is named explicitly in the live marking criteria. Your own proposal admits this is still a next step.	Problem-Solution Fit & Feasibility (15)
2	No named competitors. You describe a category, never a company.	The INSL booklet lists "no distinction from existing solutions" as a top mistake to avoid.	Innovation & Value Proposition (25)
3	No pricing numbers. Model is defined; tier prices are not.	"Initial Monetization" is named in the criteria. "We haven't decided" is a weak answer to the most predictable question.	Market Viability & Business Model (25)
4	No funding ask and no use of funds.	The Idea Stage criteria include "clear use of funds." You have none stated.	Business & Funding Strategy
5	No financial model. No costs, no break-even, no unit economics, no CAC, no LTV.	Every follow-up question in the financial direction hits a wall.	Market Viability & Business Model (25)
6	Market figures have no sources, and your own estimates are presented alongside published forecasts without distinction.	Lankan Angel Network judges check numbers.	Market Viability (25), Research Depth (15)
7	Team roles are unfilled placeholders in the proposal, and there is no founder story.	Judges score team background and storytelling.	Startup Overview, Pitch Quality (20)

Tier 2 — Fix before you meet an investor

#	Weakness	Notes
8	No legal or compliance documents at all. No terms, privacy policy, IP assignment, entity registration, or regulatory review.	The IP assignment gap is the most dangerous — it gets much harder to fix after a disagreement.
9	No local payment gateway identified or built, despite Sri Lanka being your beachhead.	A launch blocker in your own market.
10	No user persona document, no go-to-market document, no marketing plan, no scalability plan.	All four were on your own document list and are genuinely absent.
11	Risk section covers only three business risks. No technical, legal, market or competitive risks.	Sophisticated judges read a short risk list as naivety.
12	No production monitoring, CI, security audit, payment reconciliation or disaster recovery.	Expected for a prototype — but you must name them before someone else does.
13	No refund policy, no abuse policy, no handling of active passes when a merchant is suspended.	Merchants ask these in the first meeting.

Tier 3 — Internal inconsistencies to reconcile

#	Inconsistency	Where
14	Proposal says "ahead of MVP" / "concept-validation phase" — but a full working platform exists.	Proposal §6.1 vs passyn/ codebase
15	Business documents target SaaS and education; the product's merchant categories lean toward cinema, anime, streaming and OTT.	Proposal §4.1 vs lib/categories.ts
16	You position as "not a marketplace" — but the product has merchant categories and a nearby-merchants discovery endpoint.	Passyn_Context.md vs app/api/app/merchants/nearby
17	The 5% commission exists only in code (commissionBps @default(500)), never in a business document.	schema.prisma vs all business docs
18	The pricing rule is your core differentiator but is not enforced in software — a merchant can price a pass below the monthly per-day rate.	Passyn_Context.md vs Pass model
19	Pitch deck names Sabaragamuwa University (Zone C, 8 August); confirm this matches your registration, as all members must be from the same university.	PitchDeck slide 1 vs Delegate Booklet §7
20	Pitch deck and proposal contain unfilled placeholders — [contact email], [Team Leader Name], [University Name].	Both submitted documents

---

2. Questions That Cannot Be Answered From Your Documents

These returned Status: Missing Information. If a judge asks one of these, you are improvising.

Vision & team: #005 founder story · #174/#175 team roles · #178 advisors · #182 student commitment plan

Problem & validation: #018 quantified problem · #024 user willingness to pay · #227 primary validation · #233 named merchant

Business model & pricing: #090 tier prices · #094 unit economics · #095 break-even · #096 white-label pricing · #097 premium analytics feature split

Financials (whole section is thin): #149 monthly costs · #150 gateway fee rate · #151 gross margin % · #152 break-even · #153 funding ask · #157 CAC · #158 LTV · #143 churn

Market: #104/#105/#106 market figure sources · #107 ARR derivation · #113 user personas · #116 market headwinds

Competitors: #117 named direct competitors · #119 defensibility · #122 moat analysis · #124 competitive response plan

Marketing & sales: #129 scaled acquisition · #130 digital marketing · #131 SEO · #132 social · #133 affiliate · #134 named partners · #136 sales script · #139 sales cycle · #142 retention plan

Technical operations: #058 monitoring · #063 disaster recovery · #064 backups · #057 CI/CD · #055 payment reconciliation · #199 million-user scaling plan

Legal (entire section): #211 terms · #212 privacy policy · #213 regulations · #214 IP ownership · #215 data retention · #217 liability · #218 licence audit · #219 entity registration

Investors: #220 funding amount · #221 valuation · #224 exit strategy · #229 entity structure

Other: #085 build timeline · #250 name origin

---

3. Recommended Additional Research — In Priority Order

Do these five things before 8 August

1. Call or message ten merchants. Two gyms, two tuition centres, two coworking spaces, two local SaaS companies, two e-learning platforms. Ask three questions: Do people ask you for short-term access? What do you tell them? Would you sell a day pass at a premium per-day rate? Even three replies transform question #233 from a weakness into a strength. This is the single highest-return action available to you.

2. Name three to five specific competitors and write one line each on how you differ. Look at subscription and paywall management tools, membership platforms, and any local access or booking products. Closes your biggest 25-mark gap.

3. Set provisional prices. Three tier prices in rupees, plus confirm the 5% commission as a business decision. Write one sentence of rationale for each. You can revise them after pilots — but "we haven't decided" is not an acceptable answer to the most predictable question in the room.

4. Decide your funding ask and use of funds. Given your position — a working prototype, no engineering seniority, no funding — a small specific ask beats a big vague one. Format: "We are raising X to hire two engineers for N months to harden the platform, get a security review, and run three pilot merchants."

5. Fill in the placeholders. Team names against real roles, contact email and phone, university. Then write a 15-second founder story and a one-line answer to "what does Passyn mean?"

Do these before your next investor conversation

6. Build a one-page financial model. Fixed monthly costs (price the actual Vercel, Railway, Stripe, Resend stack — all public pricing), revenue per merchant, merchant growth curve, break-even month.

7. Source every market number. Label your own estimates as estimates. Write down the derivation of the 8,000–10,000 business count.

8. Identify a local payment gateway for Sri Lanka and note integration effort. Being able to name one is far stronger than "we'd look into it."

9. Sign a founders' agreement with IP assignment and equity split. Confirm whether Blansyn is registered.

10. Write the missing documents you already listed as expected: user personas, go-to-market plan, competitor analysis, scalability plan, expanded risk register.

Do these before onboarding a real merchant

11. Terms of service, merchant agreement, privacy policy, refund policy, abuse policy.
12. External security review; add MFA on admin accounts.
13. Monitoring, alerting and a CI test gate; payment reconciliation job; backup and restore drill.
14. Merchant verification criteria for the approval gate.
15. Define what happens to active passes when a merchant is suspended.

---

4. One Hundred Advanced Investor-Level Questions

Use these for deeper preparation — accelerators, incubators, and investor meetings after INSL. They are deliberately harder than the competition set. You currently cannot answer most of them from your documents; that is the point.

Market & category (1–15)

1. What is the actual number of subscription businesses in Sri Lanka with more than 1,000 paying users?
2. What percentage of a typical merchant's paywall traffic is "non-converting interested"?
3. How does that percentage differ between education and fitness?
4. What is the average price of a monthly subscription in your target segments locally?
5. What is your bottom-up TAM, built merchant by merchant rather than top-down?
6. Which of your SAM markets has the best payment infrastructure, and should you start there instead?
7. What is the seasonality of your revenue if education is your beachhead?
8. How large is the physical-access opportunity relative to digital in Sri Lanka?
9. What percentage of Sri Lankan SMEs accept online payments at all?
10. What happens to your market if bundling accelerates?
11. What is the category name you want merchants to use, and who else is trying to define it?
12. How do you know subscription fatigue is real and not a media narrative?
13. What is the addressable market if you only ever serve businesses with no engineering team?
14. What is your market share ceiling in Sri Lanka before you must expand?
15. Which single country is second, and what is the evidence?

Unit economics & finance (16–32)

16. What is your fully loaded cost to serve one merchant per month?
17. What is your gross margin on the commission line after gateway fees?
18. At what average pass price does a transaction become unprofitable for you?
19. What is your payback period on a merchant acquired through founder-led sales?
20. What is your assumed merchant churn in year one versus year three?
21. What is net revenue retention if merchants grow pass volume 20% a year?
22. How much of your revenue is SaaS fee versus commission at 100 merchants? At 1,000?
23. What is the minimum viable SaaS fee that covers cost to serve?
24. What is your revenue concentration risk if one merchant becomes 30% of volume?
25. What are your fixed costs at a team of three? Of ten?
26. How many months of runway does your ask buy, and at what burn?
27. What is your cash conversion cycle given Stripe Connect settlement timing?
28. What happens to margins if a local gateway charges more than Stripe?
29. What is your revenue per employee target at scale?
30. What would a 50% price cut by a competitor do to your model?
31. How much does an external security audit cost, and is it in your budget?
32. What is your dilution tolerance across the next two rounds?

Product & technology (33–52)

33. What is the p99 latency of your verify endpoint under load?
34. Have you load-tested anything? What broke?
35. What is your database growth rate per 1,000 passes sold?
36. How do you archive the append-only analytics table without losing reporting?
37. What is your plan for zero-downtime schema migrations?
38. How do you handle clock skew between your servers and a merchant's?
39. What happens if AUTH_SECRET rotates while QR tokens are in flight?
40. How do you prevent a merchant from enumerating other merchants' pass IDs?
41. What is your idempotency strategy for the activate endpoint under retries?
42. How do you handle a partial failure where the transaction succeeds but access creation fails?
43. What is your webhook retry policy with backoff, and is it built?
44. How do you prevent webhook delivery to internal network addresses (SSRF)?
45. What is your API deprecation policy when v2 arrives?
46. How do you version the OpenAPI spec against breaking changes?
47. What is your strategy for SDKs in languages other than JavaScript?
48. How would you extract the verification service without downtime?
49. What is your sharding key and what breaks when you shard?
50. How do you test the expiry state machine against timezone edge cases?
51. What is your code coverage percentage today?
52. Who reviews code, and what stops an untested change reaching production?

Security & compliance (53–66)

53. Have you threat-modelled the system? What is the top threat?
54. What is your incident response plan and who is on call?
55. What is your breach notification obligation under Sri Lankan law?
56. How do you handle a subject access request today?
57. Where is your data physically stored, and does that matter legally?
58. What is your policy on admin access to merchant data?
59. How do you rotate secrets, and how often?
60. What is your dependency vulnerability scanning process?
61. Is the audit log tamper-evident? How would you prove it?
62. What is your MFA plan and timeline?
63. How do you prevent credential stuffing on the subscriber portal?
64. What is your bug bounty or responsible disclosure policy?
65. How do you handle a merchant demanding access to another merchant's data?
66. What is your data processing agreement with merchants?

Go-to-market & sales (67–80)

67. What is your target list of the first 50 merchants, by name?
68. What is your conversation-to-pilot conversion rate?
69. What is the decision-maker title in each segment?
70. What is the single objection that kills the most deals?
71. What proof do you need to show before a merchant says yes?
72. How do you price the pilot — free, discounted, or full?
73. What contractual commitment do you ask a pilot merchant for?
74. What is your definition of a successful pilot, numerically?
75. What is your plan if all three pilots produce ambiguous data?
76. Which partnership would give you 100 merchants in one deal?
77. What is your inbound strategy once founder-led sales stops scaling?
78. How do you sell to a merchant whose developer must do the work?
79. What is your merchant onboarding time from signup to first pass sold?
80. What is your support cost per merchant per month?

Team & organisation (81–90)

81. What is the equity split and is it documented?
82. What happens to equity if a co-founder leaves after graduation?
83. Who is the CEO, and does the team agree?
84. What is your first hire's job description and salary?
85. How do you attract a senior engineer with no funding and no brand?
86. What is your plan for the six months around final exams?
87. Who owns the relationship with merchants — one person or all five?
88. What happens if a co-founder wants to take a full-time job?
89. What advisors do you need most, and who have you asked?
90. How do you make decisions when the five of you disagree?

Strategy & defensibility (91–100)

91. What is your unfair advantage in three years that you do not have today?
92. If a well-funded competitor launched tomorrow with the same insight, what do you do in week one?
93. What is the one metric that, if it moved, would change your entire strategy?
94. Would you rather have 500 small merchants or 20 large ones? Why?
95. At what point does white-label cannibalise your own platform business?
96. What is the strategic risk of your merchant categories drifting toward entertainment?
97. Are you infrastructure or a marketplace? Commit, and explain what you give up.
98. What is the acquisition story — who buys you, and what makes you worth buying?
99. What would make you shut this down and start something else?
100. What do you believe about this market that most people would disagree with?

---

5. Top 25 Questions Most Likely In A Startup Competition

Rehearse these until the short answer is automatic. Your live Q&A is only 2–5 minutes, so you will face roughly 3–6 of them.

Rank	Q#	Question
1	#013	What exact problem are you solving?
2	#001	What is Passyn in one sentence?
3	#029	What is your unique value proposition?
4	#033	How do you stop a merchant destroying their own subscription business?
5	#089	How do you make money?
6	#090	What exactly do you charge?
7	#117	Who are your direct competitors?
8	#106	What is your SOM?
9	#233	Name one merchant who told you they want this.
10	#147	How many merchants have you signed?
11	#232	You have no customers or revenue — what am I evaluating?
12	#236	Convince me in 30 seconds this does not cannibalise subscriptions.
13	#015	Who is your actual customer — the business or the end user?
14	#128	How will you acquire your first merchants?
15	#153	How much funding are you asking for?
16	#174	Who is on your team?
17	#011	What does success look like in twelve months?
18	#184	What are your biggest risks?
19	#104	What is your TAM?
20	#244	Why advance you over a team with paying customers?
21	#017	Why do existing solutions fail?
22	#079	What is your roadmap?
23	#022	Why can't merchants build this themselves?
24	#237	Your market numbers have no sources — where are they from?
25	#010	Why now?

---

6. Top 25 Technical Questions

Rank	Q#	Question
1	#040	Describe your overall architecture.
2	#038	What is the hardest technical part of your product?
3	#048	What is the most important API call in your product?
4	#032	What happens the moment a pass expires?
5	#046	How do you stop one merchant seeing another's data?
6	#050	How are API keys stored and validated?
7	#051	How do you handle authorization?
8	#045	Walk me through your database design.
9	#070	How do you prevent pass sharing?
10	#063	What is your disaster recovery plan?
11	#058	How do you monitor the system in production?
12	#075	Your prototype was AI-generated — do you understand it?
13	#041	Why a monolith and not microservices?
14	#069	How does QR verification work?
15	#053	How do webhooks work?
16	#054	How do payments work?
17	#055	What if the Stripe webhook never arrives?
18	#072	What testing do you have?
19	#165	Have you had a security audit?
20	#163	How do you prevent someone forging access?
21	#198	How would you handle 100,000 users?
22	#200	What breaks first as you grow?
23	#076	What are your biggest technical weaknesses?
24	#052	How does rate limiting work?
25	#247	Stripe isn't fully available in Sri Lanka — how do you launch?

---

7. Top 25 Business Questions

Rank	Q#	Question
1	#089	How do you make money?
2	#092	Why hybrid instead of pure commission or pure SaaS?
3	#098	Isn't 5% plus Stripe fees too expensive for merchants?
4	#102	What stops a merchant building it themselves after six months?
5	#120	What is your competitive advantage?
6	#122	What is your moat?
7	#119	What stops Stripe from building this?
8	#015	Who is your actual customer?
9	#110	Which single segment would you pick if you could only serve one?
10	#103	Is this a marketplace?
11	#246	Are you infrastructure or a marketplace?
12	#138	What is your sales strategy?
13	#140	What is the biggest objection from merchants?
14	#141	How do you convert a pilot into a paying merchant?
15	#142	What is your retention strategy?
16	#128	How will you acquire your first merchants?
17	#134	What partnerships would accelerate you?
18	#096	What is white-label licensing and who buys it?
19	#201	How does your business scale, not just your technology?
20	#223	What is your growth strategy?
21	#112	Sri Lanka is small — how is this venture-scale?
22	#185	What is the single biggest risk that could kill this?
23	#243	Walk me through your worst assumption.
24	#180	How do you approve merchants, and why does it matter?
25	#124	What if a competitor undercuts your commission to zero?

---

8. Top 25 Financial Questions

Nineteen of these currently return Missing Information. This section is your weakest and most predictable exposure.

Rank	Q#	Question	Can you answer?
1	#090	What exactly do you charge?	Partly
2	#153	How much funding are you asking for?	No
3	#152	When do you break even?	No
4	#094	What are your unit economics per merchant?	No
5	#148	What are your revenue projections?	Partly
6	#149	What are your monthly costs?	No
7	#154	What would you spend investment on?	Yes (undocumented)
8	#151	What are your gross margins?	Partly
9	#107	How did you calculate the US$0.4–0.6M ARR?	Partly
10	#157	What is your customer acquisition cost?	No
11	#158	What is the lifetime value of a merchant?	No
12	#143	What churn rate do you expect?	No
13	#220	How much are you raising and at what valuation?	No
14	#221	How would you justify your valuation?	No
15	#091	What commission do you take?	Yes (code only)
16	#093	What is your cost structure?	Yes (qualitative)
17	#150	What are your main variable costs?	Partly
18	#114	How many merchants before this works?	No
19	#160	What financial metrics will you report?	Yes
20	#159	How do you manage cash flow?	Yes
21	#155	Have you raised any money?	Yes
22	#156	What is your runway?	Partly
23	#099	How do merchants get paid?	Yes
24	#222	What milestones would funding get you to?	Yes (undocumented)
25	#191	What financial risks do you face?	Partly

---

9. Top 25 Product Questions

Rank	Q#	Question
1	#026	How does Passyn work, step by step?
2	#027	What are the main components of the product?
3	#028	What types of passes can a merchant create?
4	#030	Walk me through the merchant journey.
5	#031	Walk me through the end-user journey.
6	#034	Is the pricing rule enforced in software or just advice?
7	#078	What is in your MVP?
8	#079	What is your roadmap?
9	#080	What is the next feature you will build, and why?
10	#081	How do you decide what to build next?
11	#082	What did you deliberately leave out?
12	#036	Does Passyn work for physical businesses?
13	#037	How long does integration take?
14	#039	What does a merchant see that they cannot get today?
15	#084	Can you demo the product?
16	#086	What is the merchant onboarding experience?
17	#087	How will you know the product is working?
18	#088	What would make you kill or pivot this product?
19	#083	Why four portals instead of one?
20	#073	Do you have API documentation?
21	#126	Why would a developer choose your API?
22	#035	How is this different from a cheaper plan?
23	#123	How is this different from a gift card platform?
24	#077	How would you handle multiple currencies?
25	#194	What if a merchant refunds a partially used pass?

---

10. Your Five-Day Preparation Plan

You pitch on 8 August. Here is what to do with the time.

Day 1 — Close the validation gap. Message ten merchants. Two gyms, two tuition centres, two coworking spaces, four local software or e-learning companies. Three questions each. Log every reply verbatim.

Day 2 — Close the competitor and pricing gaps. Research and name 3–5 competitors with a one-line differentiation each. Decide provisional prices for Starter, Growth and Enterprise. Confirm the 5% commission as a business decision.

Day 3 — Close the funding and financial gaps. Decide the ask and use of funds. Price the actual infrastructure stack. Build a one-page model that produces a break-even merchant count.

Day 4 — Fix the documents. Fill every placeholder. Add sources to market figures and label estimates. Write the founder story, the name origin, and assign who answers which type of Q&A question. Update the progress slide to reflect the working prototype honestly.

Day 5 — Rehearse. Time your 3-minute pitch until it fits comfortably. Then have a teammate fire the Top 25 Competition Questions at you in random order. Answer with the short answer only. If you cannot answer in 20 seconds, the answer is not ready.

On the day: join 10 minutes early, test audio and video, have the deck open and ready to share, and have this document open on a second screen.

---

Document Notes

Sources used — every answer in this knowledge base is grounded in the following files, and nothing outside them:

Source	Used for
Passyn_Context.md	Vision, problem, solution, pricing psychology, revenue model, roadmap
context.txt	Same content plus INSL competition context
Passyn_INSL2026_Proposal.pdf	Problem, solution, market sizing, business model, progress, risks, competitive position
Passyn_INSL2026_PitchDeck.pdf	Team names, TAM/SAM/SOM, revenue streams, validation signals, phases
INSL_2026_Delegate_Booklet_Selected_Teams.docx.pdf	Zonal round format, marking criteria, weighting, advancement rules
DOC-20260512-WA0013_.pdf	Full INSL delegate booklet — categories, evaluation criteria, guidelines, common mistakes
DOC-20260512-WA0016_.pdf	Official proposal template structure
Passyn_API_Architecture_Guide.pdf	Plain-language API explanations, architecture framing
passyn/README.md	Tech stack, four portals, security highlights, repository layout
passyn/docs/ARCHITECTURE.md	System design, technology decisions and rationale, multi-tenancy, access engine, API-key design, rate limiting, security model, performance, deployment
passyn/docs/API.md	Endpoints, authentication, envelope, error codes, webhooks, SDK
passyn/docs/SETUP.md	Local setup, seed data, demo accounts, tests
passyn/docs/DEPLOYMENT.md	Production topology, environment variables, post-deploy checklist, operations notes
passyn/futureUpdate.txt	Multi-currency, subdomain split, third-party sign-in plans
passyn/apps/web/prisma/schema.prisma	Full data model, enums, indexes, commission basis points, statuses
passyn/apps/web/lib/*	Access engine, QR tokens, categories, API keys, rate limiting, webhooks, audit
passyn/apps/web/app/*	53 pages across four portals, 24 API routes
passyn/apps/web/tests/*	Unit and e2e test scope

Where this document goes beyond your documents, it is explicitly labelled — either as Status: Missing Information, as "not documented — this is reasoning," or in a Missing Information note. No revenue figures, statistics, partnerships, customers or features have been invented.

Passyn is a product of Blansyn · Prepared 3 August 2026 for INSL 2026 Zonal Competition, Zone C.