Parsa Riahi

Product · Restaurants and retail · 2020 to 2025

DYNE

Two products, one company. It started as a consumer app on iOS, Android and the web. It grew into an analytics and AI marketing platform that told a restaurant what demand, price, staffing and the next campaign should be. I co-founded it, ran product and engineering, and we exited.

The consumer appThe business platformAsk me about it

DYNE · The consumer app

Where it started.

01 The app

Consumer-grade, on every screen.

iOS, Android and the web, built in React and React Native, so one team could ship to all three.

CONSUMER APPSiOSAndroidWebDYNE servicemulti-tenant · Kubernetesdocument store · SSOFOR BUSINESSDemandPriceStaffingCampaigns

A diagram of the system, not a screenshot. The app screens are not on this site yet.

The app, on screen.

Screens from the consumer app go here once they are cleared.

Then the business platform.

Sales, inventory, foot traffic and what was happening outside the door, turned into the next decision.

DYNE · May 2020 to Jun 2025

Co-founder, CTO and board member.

A growth system for restaurants and retail. It read sales, inventory, foot traffic, and what was happening outside the door, then proposed demand, price, staffing, and the campaign.

+500%Marketing traffic lift.
  • Product and engineering: the service, web and mobile clients, and the models.
  • Multi-tenant on managed Kubernetes, with a document store and single sign-on.
  • Technical owner of the SOC 2 program.
  • We exited.
See the DYNE pageAll DYNE screens
  1. DYNE dashboard collage: campaigns, menu items, review scores, and a demand heatmap
    The DYNE product, as it was sold.
  2. DYNE competitor map: foot traffic heat around nearby venues in a city centre
    Competitor locations with foot traffic heat and trend filters.
  3. DYNE campaign builder: a generated dessert image beside the social post preview
    Campaign builder. A generated image and the post it becomes.
  4. Storyboard of location screens: inventory, orders, staff schedule, and inventory relocation
    Locations: inventory, orders, schedules, relocation.

How it was built.

Two of the original design diagrams, redrawn. The models behind every recommendation, and the store they read from.

Model controllerProximityCostWalkabilityTrendsCompetitionRatingsMenuRequest a predictionrouted by what is missingFeedback loopstored result, next callFormatteranswer into the twin schemaMissing-data aggregatorwhat each venue lacksVenue twin storeone twin per venuedescribed in DTDLDatabase controllerreads, writes, gaps
Figure 1. The DYNE model controller, redrawn from the design diagram. Seven models sit around one request path. A request goes to the models that can fill what is missing, the answer is formatted into a twin of the venue, and the stored result feeds back into the next request.
PeopleUserfriends, block listquest progressgift cardsrecommender memoryOrganizationmembers and rolesbilling accountVenue groupvenuesregional managersSocialMeetupguestsvenuebill and splitgroup couponReviewuser, meetup, venueaspects, scored by asentiment modelQuestvenueper-user progressVenueVenueservice inventorysubscriptionowner, groupMenu itemprices by optiontax codesOrdertable, itemscoupon, customerpayment intentGrowthCoupondeal: menu itemsvenueCampaigncouponchannelsScore and revenueper venueread by the modelsOutside servicespayments, chat, recommendations, gift cards, places, social sign-in
Figure 2. The DYNE document store, simplified and redrawn. Collections fall into four groups. A user meets friends at a venue, the venue sells from its menu, and coupons and campaigns are tied back to the venue so the models can read what worked. Outside services are drawn as one band.

DYNE · Next step

Building for restaurants or retail?

I have shipped the consumer side and the business side, and taken the platform through SOC 2. Happy to compare notes.

Email meAll industries