Questions and answers

The app is assembled from ready modules that already work for other companies rather than written from scratch. That is why the first release takes weeks rather than months and costs differently. Where a non-standard scenario is needed, our team writes it — but not the whole product.

The robot assembles the standard configuration: the chosen modules, your catalogue or schedule, the brand, the screens and the transitions between them — that happens right away. A person steps in where the decision is not obvious: integrations with your systems, non-standard screens, particular calculation logic, publishing to the stores.

Decide what should be inside and provide the content: catalogue, services, schedule, texts. Setup, assembly, publishing and support are on us.

Yes. The first build appears before signing and opens on your phone via a link, without being published to the stores.

A real one. Mobile apps are built with Dart and Flutter and compiled to machine code for iOS and Android — they install from the App Store and Google Play and work with the camera, files, notifications and biometrics.

React and TypeScript. The same logic runs in the browser and inside the mobile app, so a scenario does not have to be written twice and cannot drift between platforms.

The app keeps working with what is already loaded, and actions queue up and reach the server once the connection returns. A request sent in a lift or a car park is not lost.

Yes, there is a messenger inside: conversation with the business, attachments and notifications about new messages. The thread stays in the app rather than moving to someone else's channel where it gets lost.

Through the standard iOS and Android mechanisms — the same ones messengers and banks use. A notification can be sent to a specific person on an event: appointment tomorrow, order ready, the thing you wanted is back.

Yes, and not only push: push, email and SMS are sent from one place — to a specific person on an event, or to a segment as a list. The tool is part of the subscription; carriers and the email provider are paid at their own rates.

The content — catalogue, services, texts, campaigns — changes without republishing: edits are visible right away. Updates to the shell itself go through the stores, and we handle those.

Screens are assembled from prepared data, and heavy lists load in parts as you scroll. The app is built for the phones people carry now, not only for new ones.

Yes, if it has an integration interface. The catalogue, stock, schedule, bookings and orders sync with the system you already work in — there is no need to change it.

Then the connection is estimated separately: we need a description of the interface or access to a test environment. This is exactly the case where a person guides the assembly, not the robot.

Yours. Customer, order and booking data belongs to the business; we process it to run the app and on your instruction.

Yes. Payment is connected together with ordering or booking, including prepayment and packages. The commission is charged by the payment provider you choose.

One. The customer picks a location; each has its own schedule, prices and availability, while a membership or bonuses can work across the whole chain.

Appointments, prescriptions and documents are stored in the clinic's environment or on a protected side, and the app reaches them under agreed access rules. What data is involved is agreed before launch.

The client picks a stylist, a service and a time and sees a genuinely free slot, not a 'we'll call you back' request. The stylist gets their own access: confirming, rescheduling and blocking out time. For beauty coworking, the same scenario books a chair or a room with rent paid in the app.

Yes: the catalogue and availability come from your accounting system, service booking from the bay schedule. The owner's profile holds the VIN, mileage, service history and documents, and the work status updates while the car is in the workshop.

Yes, if your point-of-sale system has an integration interface. Takeaway orders and bookings arrive where you process them today.

It will, if the access control system can read the code. Then the pass, the membership and class booking live on one screen.

No. The industry pages are examples, not a limit. The modules are the same: catalogue, booking, ordering, loyalty, messaging; a scenario for any service or retail business is assembled from them.

A standard configuration takes weeks. The timeline is set not by the assembly but by two things: how quickly the content arrives from you and how long review takes in the App Store and Google Play.

Yes. The name, icon, colours and content are yours. In the stores it is published as a standalone product of your business.

Yours, preferably: then the app belongs to the business and stays with it whatever happens. We help set it up and go through publishing together.

We work out the reason and ship a corrected build. That is part of the work and is not billed separately.

Nothing beyond the subscription. It covers technical support, updates for new versions of iOS and Android, and platform improvements. There are no separate invoices for the app simply continuing to work.

Scenarios that are not in the modules and connecting systems with no ready integration — both quoted before the work starts. Plus app store fees and your own communication costs: campaigns, card processing, telephony.

Yes, and we recommend it. Launch the main scenario, then add modules as you grow — within the same subscription, without a new contract.

The app stops being updated and maintained. The business data is handed over to you — it is yours.