Comfandi Digital Products
- Year
- 2025
- Type
- Work project · OL-Software
- Status
- Engagement Jun – Oct 2025
- Stack
- Next.js
- Expo and React Native
- Solito and NativeWind
- Redux Toolkit
- Nest.js
- PostgreSQL and Prisma ORM
- Jest
- Turborepo
Summary
Comfandi is a Colombian family compensation fund: it offers health, education, recreation, credit and other services to the workers of its member companies and their families. At OL-Software, a software company, I worked on three of its digital products.
- A health module that lets members schedule medical appointments at the fund's clinics, check and cancel them, pay them and download their lab results. It is written once and runs on the web and on the phone.
- An assessment platform for schools, where teachers build question banks and assessments and students answer them as timed missions.
- The core services behind the fund's mobile app, where features of an older monolith were being moved into services grouped by business flow.
The main thread of my work was the health module, and in particular the appointment scheduling flow, which I built end to end. I worked on it as a Mid-level Software Engineer, from June to October 2025. This case study shows the products through their flows and diagrams.
- 3
- products worked on
- ~51%
- of the health module's commits, its top contributor
- 2
- platforms from one codebase: web and phone
Context & role
- Client: Comfandi, a Colombian family compensation fund
- Company: OL-Software
- Products: A health module for the web and the phone, an assessment platform for schools, and the core services behind the fund's app
- My role: Mid-level Software Engineer
- What I built: The appointment scheduling flow of the health module end to end, the consult, cancel and pay flows and changes to lab results; question detail, editing, the true or false type and date filters in the assessment platform; and the same-day availability rule in the health service
- Duration: June to October 2025
Problem
A member of a compensation fund uses many of its services, and each digital product tends to be built in its own way. For health, booking an appointment depends on the patient's coverage, the clinic, the specialty and the available slots, and a booking flow that gets any of those wrong sends the member to the phone line instead.
The scope of the work shows where that hurts:
- Members need to book for themselves or a relative, see what they already have scheduled, cancel it, pay it and get their lab results, on whatever device they have at hand.
- The fund needs the rules of booking, such as how far ahead to search or how close to now a slot can be, to change without a release.
- Teachers need to build and maintain a bank of questions of several types, tagged by competency, and turn them into assessments.
The member booking an appointment carries most of that weight. It is the flow with the most rules and the most ways to go wrong, so most of my work was designed around getting them to a confirmed appointment in as few steps as possible.
Users & context of use
Four profiles shape the products: the fund members who book care, and the teachers, directors and students of the assessment platform.
Fund member
Books appointments for themselves or a relative, checks, cancels and pays them, and downloads lab results.
Health module on the web and the phone
Teacher
Builds questions of several types, tags them, composes assessments and reads the results.
Assessment platform, teachers' app
Director
Manages the teachers of the school and configures assessments.
Assessment platform, teachers' app
Student
Follows a map of subjects and answers assessments as timed missions.
Assessment platform, students' app
The moments that shaped the design
- A member booking for a relative picks the patient first, because coverage, clinics and rules depend on who the appointment is for.
- A member searching on a busy day may find no slots. The search has to move forward on its own instead of returning an empty screen.
- A member who already has an appointment for the same service should be told before booking a second one.
- A student in a mission answers one question at a time with a timer, so every question type has to work with a tap or a drag.
Goals, success metrics & constraints
Goals
- Let members book a medical appointment in a few guided steps, on the web and on the phone.
- Write each screen and rule once for both platforms.
- Let the fund tune booking rules without a release.
- Give teachers a question bank they can filter, edit and keep clean.
How success would be measured
No success metrics were shared for this engagement. These are the ones I would propose:
| Goal | Metric | What it tells us |
|---|---|---|
| Guided booking | Share of searches that end in a confirmed appointment | Whether members get to a booking without calling. |
| Searches that find something | Searches that needed a retry, and how many | Whether moving to the next Monday saves the search. |
| One codebase | Screens shared between web and phone | How much of the module is really written once. |
| A clean question bank | Questions edited or deactivated per month | Whether teachers maintain the bank instead of duplicating it. |
Constraints
- The clinics' systems decide. Slots, patients and appointments live in the clinics' scheduling system, so every step validates against it.
- Local time. Appointments are in Colombia, and the server's clock cannot decide what "today" means.
- Three repositories, each with its own history. The health module, the assessment platform and the core services were already in progress, with their own conventions.
Process & prioritization
From problem to scope
The work started from the appointment flow, the most used and the most fragile. Each step of the booking became a screen of a stepper, each rule became a validation against the clinics' system or a setting, and the rest of the health module, consulting, cancelling, paying and lab results, was built around it.
What the work covered
| Area | What it enables |
|---|---|
| Appointment scheduling | A stepper with patient and coverage, service, place and date, a slot search with retries, a slot picker and a confirmation. |
| Duplicate guard | A warning when the patient already has an appointment for the same service. |
| Consult and cancel | Scheduled appointments by patient, a detail view and a cancellation with confirmation. |
| Payment | A scheduled appointment with a payment reference opens the payment portal. |
| Lab results | Orders by patient, and a PDF that previews on the web and saves on the phone. |
| Shared interface | Toasts, loading modals and a navigation hook that work the same on the web and the phone. |
| Question bank | Question detail and editing, a true or false type, and filters by creation and update dates. |
| Availability rule | A same-day margin and the Bogotá time zone in the health service. |
Design decisions
The decisions that most shaped the products, made by the team and designed by the company's product designer. Each one is shown as a flow or a diagram.
A booking in guided steps
Problem. Booking depends on who the patient is, their coverage, the service, the city, the clinic and the date. One long form would be overwhelming, and a mistake in any field means starting over.
Decision. A stepper asks for one thing at a time, validates each step against the clinics' system, and clears what depends on a step when the member goes back to change it.
Trade-off. More screens, and more calls to the clinics' system.
In the product. A patient who is not registered is sent to register first, and one without coverage can still book as a private patient.
Rules the fund can tune
Problem. How close to now a same-day slot can be, and how many times a search should move forward, are business decisions that change. In code, each change needed a release.
Decision. Both are settings: the same-day margin, two hours by default, and the number of retries per specialty. Dates are compared in Bogotá time, not on the server's clock.
Trade-off. Dates need care everywhere they are built.
In the product. An empty search moves to the next Monday on its own, as many times as configured, and today's slots that are too close are never offered.
One place for what is already booked
Problem. A member who already has an appointment needs to see it, cancel it or pay it, and that used to mean a call.
Decision. Scheduled appointments live next to the booking flow, by patient, with a detail view where cancelling asks for confirmation and paying opens the payment portal.
Trade-off. The payment happens outside the module, so the module only knows whether there is something to pay.
In the product. Lab results follow the same pattern: pick the patient, see the orders and download a PDF, which previews on the web and saves on the phone.
A question bank teachers can maintain
Problem. Teachers build questions over months. Without a way to find and edit them, the bank fills with duplicates.
Decision. Questions can be filtered by grade, subject, competency, type and dates, opened in a detail view, edited or deactivated, and true or false joined the question types.
Trade-off. Editing a question with answers and sub-questions has to update all of them together.
In the product. Saving an edit updates the question, its answers and its sub-questions in one transaction, and students see true or false questions in their missions.
Design system
The health module and the assessment platform follow the fund's visual identity, designed by the company's product designer, and both are built on the company's own component kits.
Foundations
- One typeface. Outfit for titles, interface and data, on the web and on the phone.
- The fund's blue and green. A deep blue for the brand and the main actions, with green, cyan, yellow and orange as accents.
- Grays for structure. A gray scale for borders, inputs and text, with a dark gray for body copy.
- A company kit. Buttons, cards, accordions, date pickers and modals come from the company's component kit, which I updated during the work so both platforms could use the newer components.
From design to code
As a Mid-level Software Engineer, my work was turning the design into working flows. This section explains how the products are organized, in terms of what each part does.
One codebase, two platforms
The health module is a monorepo with a web app, a mobile app and a shared package. The two apps are thin shells: every screen, rule and piece of state lives in the shared package, organized in clean architecture with atomic design, and a route table maps each route to a web address and a native screen.
Behind it, the core services are grouped by business flow: health, core settings, sales, and subsidy and credit, each with its own schema. The health service talks to the clinics' scheduling system and to an integration layer that registers new patients.
A school model behind every question
The assessment platform has a web app for teachers and directors, one for students, and an API with a module for each concept: questions, answers, assessments, results, students, groups and subjects. The data model follows the school, from the city to the group and its students, and the pedagogy, from competencies to evidence.
Simple states, strict rules
None of these entities has a long state machine. The rules sit around the states instead: one scheduled appointment per service, a question that can be deactivated without being deleted, and an assessment that counts as completed for a student once their result is saved.
Technical decisions
| Decision | Why | Trade-off |
|---|---|---|
| One shared package for web and phone | Screens and logic are written once. | Platform differences need an abstraction, such as the navigation hook. |
| Clean architecture with atomic design | A clear place for each kind of code. | More folders for small features. |
| Booking rules as settings | The fund tunes them without a release. | Defaults and formats to keep valid. |
| An explicit time zone | Slots match local time regardless of the server. | Dates need care everywhere they are built. |
| Services grouped by business flow | Each flow can change on its own. | Shared concerns move into a common library. |
Results
Members can book medical appointments in a guided flow, check, cancel and pay them, and download their lab results, on the web and on the phone, from one codebase. The fund can tune how searches and same-day slots behave without a release. Teachers can find, edit and keep their question bank clean, and true or false questions reach students' missions.
No usage figures were shared for this engagement.
Learnings & next steps
Next steps
- Measure how many searches end in a confirmed appointment, and how many needed a retry.
- Move more of the booking rules into settings as the fund asks for them.
What I learned
- A stepper is a contract with the user. Clearing what depends on a step when the member goes back felt strict at first, and it is what kept every booking consistent.
- Time zones are product decisions. "Today" meant the server's day until it was pinned to Bogotá, and a rule as simple as "not too close to now" depends entirely on that.
- One codebase needs one place for differences. Sharing screens between web and phone worked because the few real differences, such as navigation and file downloads, had a single home.