Short answer
Three habits came out of that six-week build and never left: write down your data-model assumptions and show them to the client before you create a single table, keep a deployment checklist in the project repo covering every environment variable, pinned dependency, and step from staging push to DNS update, and report progress in screens and workflows rather than engineering notes. The build itself went fine, the client was happy, and the application solved the problem it was designed to solve. What we would change is the commercial side: a brief paid technical discovery before quoting, scope locked in writing earlier, and a higher price, because complexity hides in requirements that look simple.
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.
Questions · 04
Frequently asked questions
Why run a paid technical discovery before quoting?
We estimated that first project from the brief, and the brief was incomplete. A short discovery would have surfaced the schema problem in week one instead of week four, when a new requirement needed a join we had not planned for. Estimating from an incomplete brief schedules a mid-project fire in advance.
How should a developer report progress to a non-technical client?
In screens and workflows, not engineering notes. Fixed the N+1 query on the dashboard load is meaningless to a small business owner; the orders list now loads in under two seconds, or you can now export your customer list to CSV from the main dashboard, is the same technical progress in language they can act on. What a client needs at any given moment is to know whether the project is on track.
What belongs in a deployment checklist?
Every environment variable, every external dependency versioned and pinned, and every step from staging push to DNS update. On that first go-live, missing environment variables, a dependency off by one minor release, and a hosting provider running a different PHP version than we developed against each added hours under launch-date pressure. The checklist lives in the project repo, and it has saved us repeatedly since.
How did scope creep add two weeks?
Features crept in because we said yes to small requests that individually seemed fine. Collectively they pushed the timeline out by two weeks. Locking scope in writing early is what stops small yeses from compounding.
