This interview is with Daniel Battaglia, Founder & CEO, Parksy.com.
As Founder and CEO in the internet industry, how would you describe the work you do today and the expertise you bring to building and growing online businesses?
As Founder and CEO of Parksy, a parking marketplace operating across 57 countries, my day-to-day work spans hands-on platform development using AI tooling, SEO and growth strategy, leading a small offshore team, and GM responsibilities at an e-commerce import business.
I bring over a decade of experience building Parking Made Easy into Parksy from the ground up since 2011, combined with a finance background at Lehman Brothers, RBC Capital Markets, and Macquarie Bank, which gives me both the operational grit to build and ship products myself and the commercial rigor to scale a business sustainably.
What path led you to found and lead Parksy, including ParkingMadeEasy and ParkingCupid, and how has operating bootstrapped marketplaces shaped your approach to growth?
Founding Parksy traces back to 2011/2012, when I noticed empty driveways in my Paddington neighbourhood in Sydney and launched ParkingMadeEasy to connect underused private spaces with drivers who needed them. I later expanded the model to North America under ParkingCupid, before consolidating both brands into Parksy as the business scaled across 57 countries.
Bootstrapping for over 13 years at near-zero burn has forced a founder-first, capital-efficient approach. I built and migrated the platform myself using AI tooling rather than outsourcing engineering, and I have had to earn every dollar of growth through organic SEO and lean acquisition rather than paid scale. This experience shaped a discipline of validating unit economics before spending and monetising through driver membership rather than fees on operators.
Your experience has shown that traffic can grow faster than revenue; what metric do you now use to keep customer-acquisition activity tied to genuine business value?
I’ve learned to gate every dollar of acquisition spend on real, cohort-verified LTV rather than assumed benchmarks. For Parksy, that means tracking blended ARPU and renewal-confirmed lifetime value per payer before scaling any channel, since our current renewal data supports a more conservative floor than the number our earlier ParkingMadeEasy business suggested.
Concretely, I hold spend flat until each acquisition channel’s CPA is validated against that renewal-verified LTV, not just top-of-funnel traffic or signup growth. I’ve seen firsthand — including a case where a jump in orders traced back to a payment-flow fix rather than a marketing win — that traffic and revenue can decouple in misleading ways if you’re not disciplined about waiting for the real cohort data.
When your own renewal and lifetime-value data contradicts an assumption used in your growth plan, how do you decide what to change first?
When renewal or LTV data contradict a growth-plan assumption, I go to the source ledger first — for us that’s the recurring-billing and cohort data itself, not GA4 or planning spreadsheets — because I’ve learned that funnel numbers can look real and still be an artifact of tracking or attribution bugs rather than genuine behavior change.
From there I separate signal from noise before touching spend:
- Check whether the surprise is explained by an infrastructure or product change (for example, a payment-flow fix or a broken dunning rule) before concluding it’s a genuine shift in customer economics.
- Only once I trust the number do I revise the plan — usually tightening the acquisition gate or pricing first, since those are the levers that compound fastest if the assumption was wrong.
After consolidating two long-running Drupal 7 platforms into a Drupal 11 stack, what is one principle you would recommend to founders planning a high-risk web-platform migration?
One principle I’d recommend: treat the migration like an accounting close — perform a line-by-line reconciliation between the old and new systems before you trust the new platform with live traffic.
With my CPA background, I approached the Drupal 7-to-11 migration the same way I’d audit a set of books: verifying that every listing, user record, and URL had a matching counterpart post-migration, rather than assuming a successful export/import meant parity. In a system as large and programmatic as ours, gaps hide easily and only surface as broken traffic or lost SEO equity months later.
How do you decide which product or technical debt work deserves priority when customer-facing improvements, internal tooling, and ongoing operations all compete for limited resources?
I prioritize by asking which work is currently gating a decision or blocking a measurable outcome. For instance, the dunning and attribution bugs jumped ahead of new features because they were corrupting the very data I needed to judge whether acquisition spend was working.
My priorities follow these principles:
- Customer-facing improvements get priority when there is a clear conversion or retention number tied to them.
- Internal tooling and technical debt are prioritized when they silently distort those numbers or create operational risk (for example, running production without a staging environment).
- Everything else waits until it becomes the next bottleneck.
As a founder with strengths across SEO, paid search, analytics, and content strategy, what have you learned about choosing a marketing channel that can scale without creating misleading vanity metrics?
I’ve learned to judge a channel by whether it produces revenue I can trace to a real cohort, not just growth I can point to.
Our organic SEO scaled traffic dramatically, but a chunk of that “growth” turned out to be an attribution artifact between direct and organic channels rather than new demand. For that reason, I now insist on channel-level CPA measured against renewal-verified LTV before calling anything a win.
Practically, that means I favor channels with clean, near-real-time signal over ones that merely look impressive on a dashboard.
- Paid search, with clear CPA data, earned trust faster than raw organic traffic growth.
- I will pause a channel—even one performing well on signups—the moment I can’t tie its output to paid conversions and confirmed retention.
What operating process has helped you turn customer feedback—from listings, enquiries, bookings, or payments—into product decisions without losing momentum?
The process that’s worked is building a lightweight, repeatable measurement loop rather than relying on ad hoc customer conversations. I run a weekly deep-dive script across the full funnel (signups, orders, renewals, engagement) so any shift in behavior surfaces within days, not at the end of a quarter, and I pair that with targeted feedback capture at the exact moment of drop-off, like an exit-intent survey asking non-subscribers what stopped them from converting.
What keeps momentum is treating every anomaly as actionable immediately: when the weekly numbers flagged a gap (no cancellation reasons being captured, for example), that became the next build rather than a backlog item, so the feedback loop stays tight between what customers are actually doing and what gets shipped.
You have described AI models as rented parts rather than load-bearing walls; what practical architectural choice can a startup make now to remain adaptable as AI tools and web technology evolve?
One practical choice is to keep AI providers behind an interface boundary rather than wiring their APIs directly into your core business logic. In our content pipelines, the model — GPT-4o-mini for drafting, Claude Haiku for review — is a swappable stage, not something the surrounding system depends on structurally. That way, when a better or cheaper model comes along, replacing it is a configuration change, not a rebuild.
The load-bearing walls are the things that don’t get commoditized as fast:
- our own data (listings, users, attribution history)
- our custom module architecture
- the institutional judgment about what “good” output looks like
I invest engineering effort in owning those, and treat every AI call as a rented, replaceable part sitting on top of them.
Thanks for sharing your knowledge and expertise. Is there anything else you'd like to add?
If I had to add one thing, it’s that none of this happens as a single leap. A platform migration, a conversion lift, a trustworthy LTV number — they’re all built one brick at a time. I’ve had to treat every small percentage gain (a 2% signup lift here, a fixed dunning bug there, a cleaner attribution stamp) as genuinely consequential rather than waiting for one big breakthrough.
That compounding mindset is really the throughline across everything I’ve described today:
- reconciling data like an accountant,
- isolating one variable at a time in the funnel,
- shipping fixes the week they’re found.
None of it looks dramatic in isolation, but it’s the accumulation of those bricks that has taken Parksy from an empty driveway idea in 2011 to a marketplace operating across 57 countries today.