Real projects and example scenarios

What we've actually shipped, and what a focused build can change.

The projects below are live products we built. Further down are illustrative scenarios showing the kinds of operational problems WizeApps is built to solve.

Live projects

Real products, built and shipped. Click through and see them running.

Consumer web app

Live projectBuilt in about 1 month

Mincha Time

Read teardown View live project

Problem

Mincha (the afternoon prayer) has a window that shifts every day with sunset, and it is different in every city. Without checking a calendar daily, people miss the window without realizing it.

Approach

We built a location-aware web app that calculates the correct mincha window for wherever the user is and sends an automatic reminder before it closes, with no manual setup per day.

Outcome

The tool is live and handles the calculation and reminder automatically, so users do not have to look up times themselves. A focused scope like this — one calculation, one reminder, no accounts — is what kept it to about a month.

Screenshot of Domino's Pizza Ra'anana — online ordering

Food and delivery

Live projectBuilt in about 2 months

Domino's Pizza Ra'anana — online ordering

Read teardown View live project

Problem

A local Domino's branch needed a fast, direct ordering experience — full menu, current deals, and delivery — without relying only on phone orders or a generic third-party app.

Approach

We built a branded ordering site: browsable menu, active promotions, and a delivery checkout flow, deployed as the branch's own web presence.

Outcome

The branch has a live ordering channel it fully owns, separate from marketplace apps and their fees and constraints. The menu, promotions, and checkout flow took about 2 months end to end.

Recruitment

Live projectBuilt in about 6 months

Djob — recruitment platform

Read teardown View live project

Problem

Matching candidates to open roles usually means juggling job boards, spreadsheets, and email threads with no single place to track who applied to what.

Approach

We built an end-to-end recruitment platform: candidates browse and apply to open positions, and the process is tracked in one system instead of scattered inboxes.

Outcome

The platform is live at djob.agency, giving candidates a real place to find open roles and apply directly. Covering both the candidate and employer sides of the workflow took about 6 months, reflecting the wider scope of a two-sided platform.

Illustrative scenarios

A note on these examples: the following are illustrative scenarios built from common patterns we see across small businesses and early-stage teams. They are written to explain how we approach problems — they are not descriptions of specific named clients, and any numbers shown are illustrative ranges, not measured results or guaranteed outcomes.

Hospitality

How a restaurant can stop losing reservations during peak hours

Problem

Reservation calls arrived when the team was already serving guests. Staff had to answer the phone, write down details, confirm manually, and still handle no-shows.

Approach

We map the actual flow from booking request to arrival, then build a confirmation path that records the reservation, sends a reminder, and gives staff a simple view of the evening.

Outcome

The team spends less time on the phone, guests receive clearer confirmations, and cancellations are easier to catch before the table is lost. We have not measured no-show rates for a restaurant, so we will not quote a figure. What a reminder and a one-tap cancel link actually change is that a guest who cannot come now has an easy way to say so, and the table becomes refillable instead of quietly staying empty.

Healthcare operations

How a clinic can recover hours from appointment confirmations

Problem

Confirmations were handled one message at a time. The clinic had no consistent reminder schedule, so staff spent hours chasing replies and reshuffling calendars.

Approach

We create a patient reminder workflow that confirms the appointment, follows up before the visit, and flags cancellations or unanswered messages for the team.

Outcome

The clinic keeps the human touch where it matters, while the repeated reminder work runs in the background. We have no measured time saving to report for a clinic, so we will not invent one. The concrete change is that confirmations stop depending on someone remembering to send them, and the only cases that still reach a person are the ones where a patient did not reply or asked to move the visit.

Startup MVP

How a founder can test a marketplace idea before building too much

Problem

The founder had a service marketplace idea with too many possible features and no clear first version. Building everything would have delayed the first user test.

Approach

We reduce the product to the core loop: a provider profile, a request flow, a match step, and a basic admin view to manage early activity.

Outcome

The founder can test demand with real users and make product decisions from usage rather than guesses. For a sense of scale from work we have actually shipped rather than a projection: Mincha Time's first usable version took about a month, while Djob — a two-sided matching platform with a far wider scope — took about six months.