Senior software engineer who designs and ships the systems a business runs on.

The problem

Alphera Marine Services recruits and manages seafarers. Before this project the company had no system at all. Every step, from a crew member's first application to the accounting entries at the end, was done by hand and kept on paper.

The brief was to replace all of it with one platform: recruitment from start to finish, crew records, payroll and accounting.

My role

I led a team of four developers and worked directly with Alphera's stakeholders on requirements. I owned the system design and the deployment to production, and I wrote code across the stack.

What made it hard

The code was not the hardest part. Two other things were.

The developers and the stakeholders did not share the same knowledge. The people at Alphera knew maritime crewing in detail and had never specified software. My team knew software and had never run a crewing operation. Because nothing had been automated before, the stakeholders wanted every form and every exception built in.

Going live meant moving a paper operation into a database. There was a large number of forms and existing records to bring across before staff could stop using paper.

Decisions

Understand each request before deciding when it ships. The stakeholders asked for everything at once. I did not argue about what was in or out. I took each idea, worked out what it was for, and then decided which pieces had to ship first and which could follow.

Meet on site every week. I interviewed the staff about how they worked and held a weekly meeting at Alphera's office to keep both sides aligned. The purpose was shared knowledge: my team learning the crewing process, and their team seeing what the software would and would not do.

Make the import match their paper, not our schema. For the existing records we built a bulk upload that accepts the same layout staff were already using by hand. They did not have to reformat years of records to fit the system, and the migration became a task they could run themselves.

Build the override we first left out. We misunderstood one part of recruitment. We built it so that an applicant had to complete every requirement before they could be onboarded. In practice a recruitment manager can make an exception and move an applicant forward with a requirement still outstanding. We reworked the flow so that override sits with the recruitment manager's access. I now ask "who is allowed to break this rule?" before I build any rule into a system.

Result

The system took at least a year to build and is in production today. More than fifteen staff use it across recruitment, payroll and accounts, it holds hundreds of crew records, and Alphera runs its operation on it in place of paper.

The problem

People save things everywhere: a link in one app, a screenshot in the camera roll, a post bookmarked in another. Finding one of them a month later means remembering where it went.

Vaultr is one private place for all of it. You share a link, image or screenshot into the app from anywhere on your phone, and later you search for it in plain words. It reads the text inside images and writes a short description of each one, so a screenshot can be found by what it shows.

My role

Vaultr is a two-person product I built with Miguel Kalaw, a developer I used to mentor. I wrote a large share of the application code across both platforms, including the interface, collections, backup flows and the Android side of image description, and I handled the store submissions. It is published on the App Store under Miguel's developer account.

Decisions

Nothing leaves the phone. There is no account, no server and no sync. The vault is a database on the device. That ruled out the easy route for the hard features, because search and image understanding could not be sent to a cloud service. In return, the App Store privacy label reads "Data Not Collected", and that is the product's main promise.

Run the models on the device, and be honest about the cost. Text in images is read with the platform's own recognition. Image descriptions come from a vision-language model that runs locally: FastVLM on iOS and SmolVLM through llama.cpp on Android. These models are large, so the app tells the user the download size and the free space needed before it starts, and onboarding waits for the download to finish before letting them in.

Backups are encrypted with a key only the user holds. With no server, a lost phone means a lost vault unless the user has a backup. The app exports an encrypted backup file protected by a recovery key the user chooses, and they can store that file wherever they like. Restoring shows a preview first and makes a safety copy before replacing anything.

Keep the interface we had. We planned to rebuild every screen in each platform's native toolkit. Partway in, the toolkit we were relying on turned out to be too limited, and the existing screens were already fast and polished. We stopped, kept React Native for the screens, and used native components only where they clearly helped, such as the iOS search bar. Dropping a plan we had already written down was the right call.

Result

Vaultr is live on the App Store as a paid app for iPhone and iPad, and it is listed on App Builders PH. It works with no account and collects no data.

The problem

I run a coffee shop. When the schedule got busy enough to hire staff, the hard part was not the hiring. It was getting each new person to make every drink the same way I do, without me standing beside them. Recipes lived in my head and in chat messages, and portions drifted.

Ratio is the tool I wanted: an owner writes each approved recipe once, with exact amounts and steps, and staff follow it on their phones. It is built for any shop that prepares items by measure. The first beta is for independent coffee shops in the Philippines.

My role

Ratio is my own product. I wrote the specification, designed the data model and built the application.

Decisions

Staff never see a recipe change underneath them. Editing a published recipe creates a draft, and staff keep seeing the approved revision until the owner publishes. A guide that is already open on someone's phone stays as it was, shows a notice that an update exists, and only loads the new version when the person asks for it. The alternative, live updates, is simpler to build and would change the amounts in front of someone halfway through a drink.

A unit conversion is refused unless the owner has defined it. Grams convert to kilograms freely. Grams to milliliters, or a "pump" to milliliters, needs a density or an equivalent that the owner has entered for that ingredient. Published recipes keep the definitions they were approved with, so editing an equivalent flags the affected recipes for review. It does not quietly change quantities that staff are already following.

Each shop's recipes are isolated in the database, not only in the application. Every shop is a private workspace, and the separation is enforced by row level security in Postgres. A set of database tests checks that one business cannot read another's recipes, photos or staff. Support access to a shop's recipes needs the owner's permission and leaves an audit record.

The words on screen can change; the schema does not. A shop chooses whether its items are called "drinks" or "recipes". That choice is a label for screens and emails only, which kept a late change in positioning from turning into a migration.

Result

Ratio is built through external beta readiness: invite-only registration, recipe publishing, staff invitations, printable guides, a full export, and the trial and billing states. The separation checks pass. It is not yet deployed, and it has not been tested with a real shop other than my own, so whether owners can set it up without my help is still unproven. That pilot is the next step.

The problem

Deja Bros is my coffee shop. Orders were written on paper receipts, and sales and expenses were typed into a spreadsheet afterwards. That worked, but it told me nothing until I sat down and added things up. I wanted every sale recorded as it happened and a clear picture of how the business was doing.

My role

I designed and built it alone, and I am also the customer. It runs on a tablet at the counter and takes 10 to 20 orders a day.

Decisions

Model the menu the way a barista says it. Variants and options were the hardest part. A drink is not one product with one price. It has variants, such as size, and each variant has its own price and its own stock. On top of that come options, the add-ons a customer asks for. I gave each level its own table, product then variant then option, so the order screen can walk the same steps a barista does when taking an order.

An order keeps its own copy of the price. Each line on an order stores the price it was sold at, and each add-on is copied onto the order with its name and price. Changing the menu next month does not change what last month's sales say. For a tool whose purpose is to show how the business is doing, the history has to stay true.

Track expenses in the same place as sales. The spreadsheet held both, so the system does too. Expenses are entered alongside orders, and the reports read from both. Recording only sales would have left half of the old spreadsheet alive.

Keep payments simple. The shop takes cash and GCash, so the order records which one was used and nothing more. There is no payment integration to maintain for a counter that handles 20 orders on a busy day.

Result

The shop runs on it every day. Paper receipts and the sales spreadsheet are gone, and the reports show sales and expenses without anyone adding up a sheet. The portion control section of this system is where the idea for Ratio came from.

The problem

The HeartyGrubPH sells meal packages for delivery, from two branches that each cover different areas. The business needed a site where customers could choose a branch and a package, order and pay online, and where the owners could manage those orders. The menu changes every week, and each week has an order cutoff, so the site also had to know which orders belong to which delivery week.

My role

This was my first project as the lead, and I was still a junior developer. I built the backend and worked with one front-end developer. There was no senior engineer on the project to ask. We delivered it in four months.

Decisions

Payment status was the part I got wrong first. I integrated the payment gateway without knowing what a webhook was, and the provider's documentation did not make it clear. So I did not let the gateway tell the system when a payment succeeded. I built it the other way round: a queued job collected every unpaid order and asked the gateway about each one, then updated its status.

What that cost. The approach worked on the day a customer paid and came straight back. It did not hold up under how people really behave. Customers closed the tab, paid late, or abandoned the checkout, and the system was left with a large number of floating orders that were neither paid nor clearly cancelled. Someone had to work out what each one meant.

What I took from it. I had designed for the one path where everything goes right. Payment is the place where that matters most, because the customer, the gateway and the system each believe something different until they are reconciled. I now start any payment work from the provider's event notifications, decide what every order state means before writing code, and give unpaid orders an expiry so none are left floating.

Result

The platform is live and handles more than 100 orders a week. It is also the project that taught me to design for what users do, not for what the happy path assumes, and that is the habit I bring to every system I have led since.