Shipping our first custom web application for a paying client taught us more in six weeks than the previous year of side projects combined. We are a young studio out of Silang, Cavite, and this was the moment the theoretical became real. Here is what we took away.
The Database Schema Conversation Nobody Warned Us About
We spent the first week arguing about the schema. Not loudly - we only had two people on the project - but the disagreement was real. One of us wanted to normalize aggressively. The other wanted to keep things flat and ship faster.
We ended up somewhere in the middle, and the compromise haunted us in week four when a new requirement needed a join we had not planned for. The lesson was not "always normalize" or "always keep it flat." It was: write down your assumptions early and show them to the client before you write a single table. That forces both sides to agree on what the data model is actually supposed to support.
Assumptions undocumented are bugs waiting to happen.
Deployment Was Not One Step
We had tested locally and on a staging server. We assumed going to production would be a copy-paste of what we had done before. It was not.
Environment variables were missing. A dependency version was off by one minor release. The hosting provider's PHP version was not what we had developed against. None of these were catastrophic, but each one added hours and added pressure because the client was watching a launch date.
What we put in place after that first go-live: a deployment checklist that lives in the project repo. Every environment variable is listed. Every external dependency is versioned and pinned. Every step from staging push to DNS update is written out. It sounds boring. It saved us repeatedly.
Communicating Progress to a Non-Technical Client
The client ran a small business. They did not know what a foreign key was and did not need to. What they needed was to understand, at any given moment, whether the project was on track.
We were sending updates that read like engineering notes. "Fixed the N+1 query on the dashboard load." Meaningless to them.
The shift we made was to write updates in terms of screens and workflows. "The orders list now loads in under two seconds" or "you can now export your customer list to CSV from the main dashboard." Same technical progress, different language.
This sounds obvious in hindsight. It was not obvious when we were deep in the code and tired.
What We Would Change
Three things, looking back.
First: we should have done a brief technical discovery before quoting. We estimated based on the brief, and the brief was incomplete. A short paid discovery would have caught the schema problem before it became a mid-project fire.
Second: we should have locked the scope in writing earlier. Features crept in because we said yes to small requests that, individually, seemed fine. Collectively they pushed the timeline by two weeks.
Third: we should have charged more. Not because we needed more money (we needed more sleep), but because the pricing did not reflect the actual complexity. Our first real custom software project taught us that complexity hides in requirements that look simple.
The Part That Went Right
The client was happy. The application worked. It solved the problem it was designed to solve. We shipped.
None of the lessons above change that outcome. They just mean the next project was faster, smoother, and better scoped. That is what a first build is for.
If you are thinking about a custom web application for your business, we would rather have an honest conversation about what it actually requires than give you a number before we understand the problem.