The pieces and their boundaries are settled before code.
Several institutions, one system, records kept apart.
One codebase, both stores: iOS and Android.
We take a running system over and improve it.
AI only where the problem actually calls for it.
Patients type in their lab values and a physician writes the reading. The public site takes the values, the doctor's panel is where the interpretation is written and approved, and a mobile app tells the patient the moment it is ready.
Visit the site →A lab printout is a grid of numbers, reference ranges and abbreviations. It answers a question the patient did not ask, and the one they did ask is nowhere on the page, so that question goes to a search engine, or into an appointment. Tahlil.com sits in that gap. One rule was drawn before anything was built: the system prepares a reading, and a physician approves the words that reach a patient. Everything else follows from that, down to the doctor’s panel being the one place an interpretation is written and signed off.
We go through how the work runs today and what you expect from the software; the scope comes out of that.
We decide what the system is made of and where its information is kept.
We draw the screens and the flow before any code, and start building once you have approved them.
We write and hand over the software so another team could carry it on.
A patient types one value and sees where it sits against the reference range, which is a way into the platform that costs nobody an appointment.
The system drafts a first reading; the doctor edits and approves it in the panel, so the wording a patient reads is the doctor's.
One React Native (Expo) codebase ships to both stores; OneSignal pushes a notification the moment a physician signs off an interpretation.
Site, panel and app all read the same Laravel application: MySQL holds the records, Redis carries the cache layer, Tailwind drives the web interfaces.
| Challenge | Result |
|---|---|
| A printed lab report gives reference ranges and abbreviations, nothing that reads as an answer | A patient reads an interpretation that a physician has put their name to |
| A short explanation still costs an appointment, and physicians answer the same question repeatedly | A calculator answers the simple question without a booking being made |
| The patient site, the doctor panel and the patient app all have to share one data model | All three surfaces read one record, so approved in the panel means approved in the app |
| AI can prepare the reading, but the physician has to own the final wording | Responsibility for the wording stays with the physician who signed it |
Our own workshop software, built around the car on the ramp. A work order, the parts it consumes and the invoice it produces run as one chain, and the accounting side hangs off that same record. Maintenance history lives on the plate and chassis, so it travels with the car.
Our own product for HVAC, boiler and appliance service companies. The customer and device records the office works from are the same ones the technician carries into the field. A job can be opened and closed in a basement with no signal, and service history stays tied to the device.
Our own product, still in development and not yet live. How long an appointment runs, what it is booked against and how bookings stack all differ by trade, so we are keeping those rules configurable inside the product instead of fixing them in code.
Tell us how the work runs today and we will look at which step could move into software.
