Ziinkle was founded in Sydney in 2021 by Melanie Leahy and Elisse Alexander, who came out of their own experience of dating apps convinced the format was working against the outcome. Endless swiping and open-ended messaging kept people inside the app; it did not get them into a room together. The founders wanted to invert that, so the unit of discovery was a place rather than a profile card - who is here, now, at this bar. That is a straightforward idea and a difficult product. The moment an app tells one stranger where another stranger physically is, safety stops being a feature and becomes the architecture, and the privacy model has to be settled before a single screen is designed.
How we built a dating app around the venue someone was standing in, with anonymity as the default setting.
Built around the room you are in
Ziinkle was an Australian dating app PixelForce designed and built for iOS and Android, with an admin portal behind it. Instead of an endless profile feed, it showed singles who else was physically present at the pub, cafe or restaurant they were in, governed by a visibility model that kept every user anonymous unless they chose otherwise and reset itself every twenty-four hours. The product is no longer operating, and this page is a record of what was built.
Raised by Ziinkle before launch AUD 455,000
National launch July 2022
Platforms iOS + Android
The Problem
The Solution
PixelForce designed and built the apps for iOS and Android and the admin portal behind them. The core was a presence layer: venues were drawn from a third-party mapping service, users were recognised at a venue by location, and each venue pin carried a live count of the Ziinkle users inside it. Over that sat a three-state visibility model - visible, anonymous or incognito - which defaulted to anonymous, expired after twenty-four hours and reset itself, so exposure was always an active choice with a time limit rather than a setting someone forgot they had changed. Accounts were tied to a single verified mobile number through SMS authentication, and profiles could be photo-verified.
The Outcome
The apps shipped on iOS and Android with real-time chat, photo verification, free and premium tiers sold through in-app purchase, and an admin portal for user management, moderation and reporting. Ziinkle launched nationally across Australia in July 2022 after a New South Wales test launch, following a capital raise in which the company took just over AUD 455,000 from 202 investors through the equity crowdfunding platform Birchal - a client fundraising result rather than one PixelForce produced. The product is no longer operating.
Presence as the unit of discovery
The founders of Ziinkle framed the problem as a mismatch between what dating apps optimise for and what their users actually want. An app is rewarded for keeping two people typing; the people themselves want to meet. Ziinkle's proposition was to skip most of the typing by making physical presence the thing you matched on. Open the app in a bar and you would see how many other Ziinkle users were in the room, filtered to your preferences, and could start a conversation with someone thirty seconds away rather than thirty kilometres.
Two constraints shaped the whole build. The first is that a location-based social app inherits a safety obligation an ordinary dating app does not, so data privacy and user control had to be settled in scoping rather than retrofitted. The second is that a presence product is worthless when nobody is present, so every decision about counts, visibility and empty states had to work on a night when a venue held one Ziinkle user, not just on the night it held forty.
Presence, not a profile feed
Discovery was organised around venues rather than an infinite card stack. That changed the data model, the map, the notification logic and the empty states all at once.
Anonymous by default
Every user was anonymous unless they deliberately made themselves visible, and that choice expired after twenty-four hours and reset. Exposure was always opt-in and always temporary.
Venue data we did not own
Venues came from a third-party mapping service, so the build needed place-type allowlists, keyword exclusions, clustering, radius search, and sensible behaviour when a listing had no image or trading hours.
Safety as an architectural requirement
One account per verified mobile number, optional photo verification, keyword screening on free-text fields, and block and report flows with defined retention windows - all scoped before design started.
Ziinkle ran from Sydney and PixelForce worked from Adelaide, so the engagement was structured to hold together without a shared office. Requirements were settled in writing before development started, the build ran in fortnightly sprints planned by the whole team including quality assurance rather than by developers alone, and the project closed with a formal retrospective. Joint sprint planning was the practice the team carried forward: when testers help set the order and depth of testing, a feature as sensitive as venue visibility does not reach a release candidate untested.
Hinney Lo Founder & CEO, PixelForce
Book a consultationOn a location-based dating app, the privacy model is the product. We spent the scoping phase arguing about what a number on a map means when there are two people in the room, and whether a visibility setting should still be on tomorrow morning. Those are not settings screens. They are the reason someone does or does not feel safe opening the app in a bar.
Swipe to explore
How we built it
The engagement began with Phase 1 Scoping and Design, which on this product carried more weight than usual. Workshops produced a Business Requirements Document, the UX/UI design, a Product Requirements Document and a fixed-cost Statement of Work. Scoping and design always precedes development at PixelForce, and here that was not procedural: the visibility rules, the retention window on a blocked profile and the exact meaning of a number on a map are safety decisions, cheap to change on paper and expensive to change in code. The solution design was written to that level of detail, down to what the app should say when a user was the only person checked in at a venue.
The presence layer was the technical centre of the build. Venues were pulled from a third-party mapping service and constrained by an allowlist of place types and an exclusion list of keywords, so the map showed bars and cafes rather than petrol stations. Users were recognised at a venue by location, removed automatically when they left, and prompted to choose when the device placed them at two venues at once. Each pin carried a live count of the users inside, deliberately blunted at both ends because a precise small number in a small room identifies people. Search worked by suburb or venue name with a radius around the selection, results read as a map or a distance-ordered list, and pins clustered as the user zoomed out.
Over that sat the trust and communication work. Profiles could be photo-verified through a guided selfie flow reviewed in the admin portal, and verified profiles carried a badge wherever they appeared. Free-text fields were screened against a client-managed keyword list. Real-time chat opened only on a mutual like, and unmatch, block and report were first-class actions with explicit rules about what each party could still see and for how long. Free and premium tiers were sold through in-app purchases after a thirty-day trial. The admin portal gave the client user management, content control, moderation queues and analytics, and every release moved through documented quality assurance and a release checklist before submission.
Arrive · Appear · Meet
Anonymous by default, visible by choice, reset every twenty-four hours.
A dating app where the match was the person across the room.
- Venue search and check-in
- Three visibility modes
- Counts that do not identify people
- Photo verification
- Chat, block and report
- Free and premium
01 06
Venue search and check-in
Venues were drawn from a third-party mapping service and filtered to relevant place types, then shown as pins on a map or a list ordered by distance. Users could search by suburb or venue name, which recentred the map on a radius around the selection. Location permission and GPS were hard requirements, and the feature blocked cleanly with a route into device settings when either was off.
02 06
Three visibility modes
Visible put a user's profile inside the venue. Anonymous counted them without showing them. Incognito removed them from the venue entirely. The default was anonymous, and any change expired after twenty-four hours and reverted, with a live countdown shown to the user. Making exposure temporary by design meant nobody was left publicly visible because they forgot a setting from last weekend.
03 06
Counts that do not identify people
Each venue pin carried the number of Ziinkle users inside it, drawn only from users set to visible or anonymous. Fewer than three showed as a threshold rather than an exact figure, and more than ninety-nine showed as a ceiling. A precise small number in a small room tells you who someone is, so the count was deliberately blunted at the low end.
04 06
Photo verification
Users could verify themselves through a guided flow that captured a live selfie in a specified pose. Submissions were reviewed in the admin portal and approved or denied, with the outcome pushed back to the user. Verified profiles carried a badge everywhere they appeared, including inside a venue, which is where it matters most.
05 06
Chat, block and report
A chat thread opened only when two users liked each other, and a message could be attached to a like so it was waiting the moment the match landed. Unmatch, block and report were first-class actions with explicit rules: a blocked user disappeared from discovery, neither party could send another message, and each retained read access to the history for a defined window so an incident could still be evidenced.
06 06
Free and premium
Every new account started on a thirty-day trial of the premium features. Free users could see and act on the most recent person who had liked them, with the rest of the match list blurred; premium users saw the whole list and a wider set of filters. Subscriptions were handled through the platform in-app purchase systems.
Services on the Ziinkle build
Frequently Asked Questions
Ziinkle was an Australian dating app for iOS and Android, designed and built by PixelForce, an Australian digital product agency. It was founded in Sydney in 2021 by Melanie Leahy and Elisse Alexander. Rather than an endless profile feed, Ziinkle organised discovery around venues, showing users how many other Ziinkle users were physically present at a bar, cafe or restaurant, governed by a visibility model that kept everyone anonymous by default. It launched nationally across Australia in July 2022 after a New South Wales test launch.
No. Ziinkle is no longer listed on the Apple App Store or Google Play and the company appears to have wound down. This page is published as a record of the engineering PixelForce delivered, not as a link to a live product. Nothing here should be read as a claim that the app can be downloaded today.
PixelForce delivered the iOS and Android apps and the admin portal behind them. That covered SMS-verified signup and onboarding, profile creation and preferences, venue search over third-party mapping data with map and list views, the three-mode visibility system, the like and match flow, real-time chat with unmatch, block and report, photo verification, free and premium tiers sold through in-app purchase, and an admin portal for user management, moderation and analytics.
By deciding the exposure rules before designing any screen, and by making exposure opt-in and temporary. On Ziinkle the default state was anonymous, being visible was an explicit choice, and that choice expired after twenty-four hours and reverted automatically. User counts at a venue were blunted at the low end so a precise small number could not identify an individual. Accounts were tied to one verified mobile number, and block and report carried defined retention windows.
Cost depends on scope, and scoping and development are priced separately at PixelForce. Phase 1 Scoping and Design runs $35,000 to $65,000, and Phase 2 Development, QA and Release typically ranges from $100,000 to $350,000. A location-aware dating app sits toward the upper end, because real-time chat, mapping integration, verification, moderation tooling and an admin portal are all in addition to the matching experience. The exact figure is fixed in a Statement of Work at the end of Phase 1.
PixelForce runs every engagement in the same sequence: a free consultation, then Phase 1 Scoping and Design producing a Business Requirements Document, UX/UI design, a Product Requirements Document and a fixed-cost Statement of Work, then Phase 2 Development, QA and Release, then Phase 3 Post Launch Support. Scoping and design always precedes development, so the timeline is fixed once the product is defined. On a safety-critical product that ordering is what prevents a rewrite.
Yes. Phase 3 Post Launch Support is a standing part of every PixelForce engagement, offered as a warranty, monitoring and support option at $4,000 per month, or as a product retainer from Steady at $10,000 to Momentum at $50,000 per four-week cycle for clients who want continuous development. For a product with a moderation queue and a live safety surface, ongoing support is not optional.
Up next
More products we have designed, built and launched end to end.
Train With Cass Stabilise first, decide second
Crash rate down 90 percent, 99 percent uptime, and maintenance costs cut in half - without a day of disruption for members.
1MAC Anesthesia A direct line into anaesthesia coverage
How we built a two-sided marketplace where anaesthesia providers and United States healthcare facilities deal with each other directly.