Bloom

Bloom is concept work, and we say so plainly wherever it appears: there is no client behind it, and it should never be read as a customer having chosen Appluex. We build concept products because they let us work through a hard domain end to end, at full design and engineering quality, without a live schedule forcing shortcuts. Telehealth earned that investment. It combines regulated, sensitive data, real-time video, a two-sided dynamic between patients and providers, and a user who often opens the app in a vulnerable moment. Designing well for that combination is the actual portfolio piece.

Privacy was the first constraint, not a feature on a list. Health information is among the most sensitive data an app can hold, so Bloom's design keeps it minimal, encrypted, and scoped: messaging between patient and doctor is encrypted, video consultations are secure by design, and the backend is structured so a provider sees only the patients who chose them. Working through those boundaries as an architecture exercise, rather than a compliance checkbox added late, is exactly the kind of thinking a real telehealth engagement demands on day one.

The product design centers on the two decisions that gate access to care: finding the right doctor and affording the visit. Provider discovery is organized around specialty, so a patient dealing with a chronic condition or a mental health concern searches by what they need rather than scrolling a directory. Pricing is tiered, with free consultations included, because affordability is not a discount on the same product: it is a separate path through the app that has to feel just as complete, from booking through follow-up messaging.

On the engineering side, Bloom pairs a Flutter app with a Node.js backend on AWS. Appointments, provider profiles, and the relationships between patients and doctors live in PostgreSQL, because scheduling and care relationships are exactly the kind of data where relational integrity earns its keep: a double-booked slot or an orphaned appointment is not a cosmetic bug in healthcare. Firebase carries the real-time layer, keeping messaging and appointment updates immediate, while the AWS footprint is sized to grow with a provider network rather than be rebuilt for one.

What a concept like Bloom demonstrates is range, honestly labeled. The screens, the flows, and the architecture decisions are real work you can inspect, and they transfer directly to a funded telehealth product: the discovery model, the tiered pricing paths, the privacy boundaries, and the scheduling core would be the same conversations with a real client. If you are planning a telehealth product, Bloom is the groundwork for that conversation, not a substitute for it.