Capstone and Asking the Right Questions
July 17, 2026
Every MIS major at Ateneo goes through a capstone, a three-semester consulting engagement that starts in third year. A student team gets attached to a real company with a real problem, and the grade depends on whether you actually solve it. If you break something, someone's business feels it.
Ours was ROQSON Industrial Sales, a 40-person Petron lubricant distributor in Quezon City. Orders arrived through paper forms and Viber messages. Records lived in Excel and an aging sales system called TRACC. By the numbers in our final paper, the gaps were costing the company about ₱853,000 a month, roughly 23% of its monthly sales target.
We were five people. One ran project management, one ran QA, one ran training, one led our original ERP platform, and I was Data Management Lead and Developer. Midway through, the two of us doing development split the system down the middle, and I took orders, trips, and deliveries, the half of the business that's physically on the road every day.
I've written separately about why we threw out our original platform and started over. This piece is about what I did within all that.
Finding out what the rules actually were
The hard part of building for a small distributor is that nobody, including the client, has ever written down how the business works. The rules live in people's heads, and you extract them one slightly embarrassing question at a time.
I was one of the main lines to the client, so a lot of those questions were mine to ask. For weeks we had modeled a "trip" as a truck's full journey: out from the warehouse, through its deliveries, back home. Then on a call I learned that at ROQSON, a trip means one leg, from point A to point B. Everything downstream of our assumption, the trip tickets, dispatch, delivery status, had been built on the wrong shape, and we only found out because I asked a question that felt too basic to ask.
The same thing kept happening. Can a trip carry orders from two different customers? No, one customer per trip, though that customer can have several orders, so I built the form to enforce exactly that. What counts as low stock? Nobody had a number, so we had to go get one. When a delivery fails, does anyone record why? They do now. The form links each failure to the specific items that caused it, so a manager reviewing a bad week can tell whether the problem was stock, the customer, or the route.
Building the order-to-delivery flow
Our final paper's changelog credits me with 95 shipped changes. Most of them are small and boring on their own, which I mean as a compliment, because together they take those judgment calls and bake them into software the staff can't get wrong even on a bad day.
The ones I'd point a stranger to:
- Orders lock after a salesperson submits them, and an order with no modifications skips the approval queue entirely, so managers only ever touch the exceptions.
- Changing a price triggers an approval pop-up with a required reason. Before this, a discount was a verbal agreement and a memory.
- Payment terms fill in from the customer's record and can't be edited freely. A salesperson who wants different terms files a request with a reason. This closed one of the quieter ways money leaked.
- The promo engine. Buy-this-get-that sounds simple until a real order has two promos at once, a reward item that has to come out of an actual warehouse, and a salesperson who fat-fingers the quantity. I built the checks for all three, mostly by breaking it all three ways first.
- Drivers open the app and see only their own trips for today. Field staff never see unit costs or VAT.
- Delivery proof: time in, time out, a timestamped photo, a signature, captured on a tablet at the customer's door instead of reconstructed from memory back at the office.
Each of these is a business rule I had to go find, verify, and then make unbreakable, and the finding and verifying took far longer than the building.
Owning whether the data could be trusted
Systems like this die quietly at the data layer, usually the first time a manager opens a report and sees a number they don't recognize. After that they stop trusting the system, and no feature wins them back.
So the master data was mine. Customer records, product records, reorder levels, payment terms. The address data was messy enough that the normal import tools gave up, so I rebuilt it against the government's official location registry, and now every address in the system resolves to a real barangay. That one took until three in the morning. I have complicated feelings about addresses now.
The real test came in April, two days before handover, when we replayed ROQSON's entire January 2026 through the system. All 1,023 orders across 512 customer accounts, pulled from their actual records, to see whether our numbers matched theirs. I ran the simulation, and partway through, the inventory showed 702 products with only 21 in stock. Which is a fun thing to discover 48 hours before you hand a company its new system.
The cause turned out to be a real operational habit nobody had mentioned: ROQSON converts products between pack sizes as part of normal work, and our stock logic had no idea. I worked out the conversion rules with the client and adjusted the data so the replay could finish.
The final reconciliation matched 91% of January's sales value, about ₱25.1M of ₱27.6M, and the missing 9% traced entirely to 230 walk-in customers who had never been in ROQSON's own database to begin with. Inventory matched exactly across all three warehouses. I could have shrugged at "close enough," but chasing the gap down to a named cause is what let the sponsor accept the system on the numbers.
Moving the whole thing without dropping it
When we scrapped the original platform, eight months of configuration and client data had to cross to the new system without loss. I wrote the migration plan, published it to the team so everyone knew how our way of working was about to change, and executed it table by table with a backup at every step, since a half-migrated system would have been worse than either the old one or the new one.
A teammate asked about the risk section of the plan. I told her not to worry about it, since the risks were mine to carry, and writing them down was how I made sure I was carrying them on purpose.
At handover, the deployment and credential transfer were also mine. The sponsor's team walked away holding the keys, the source code, and a permissions dashboard I built so they can change who's allowed to do what without calling us.
What this project actually proves
I used AI coding tools heavily and openly throughout, and I burned through usage limits doing it. The speed only mattered because of everything above, though. A tool can write a delivery form in a minute, but it can't know that a trip runs from A to B, that a trip holds exactly one customer, or that a 9% reconciliation gap is 230 walk-ins rather than a bug. I was one of the people on the team carrying that knowledge, and pairing it with fast tools is the whole reason two student developers could ship a ten-module system that a company now runs on.
The system was validated against ROQSON's real January and accepted by the sponsor in April 2026. Salespeople file orders from the field. Dispatchers assemble trips from live records. Managers see which customer accounts are going quiet and how much stock to order next month, instead of stitching that picture together by hand. Whether the ₱853,000 a month comes back depends on sustained use, and I won't claim it until it has.
The question I keep coming back to is narrower than "digital transformation." How do you give a 40-person distributor software that fits the way the work already moves, and then makes the better version of that work the easier one to do? Most of my answers came from asking basic questions, chasing small gaps to named causes, and refusing to ship a rule I didn't understand.