What I learned shipping my first freelance client site

The project

Bangalore EduConnect is an education consultancy helping students choose engineering colleges. They needed a site that explained the service quickly and made it easy to get in touch. It was my first paid delivery, and it is still live.

I expected the hard part to be the build. It was not. The build was HTML, CSS, JavaScript, and a PHP handler for the enquiry form. I had done all of that before.

Lesson one: the contact flow is the product

My first design put a tidy enquiry form at the bottom of the page. Sensible structure: explain, then convert.

The client pushed back, and they were right. Their visitors are often parents on a phone, mid-decision, who want to talk to a person now. Scrolling to a form at the bottom is friction at exactly the wrong moment.

The final build puts the enquiry form beside the hero, and keeps a floating call and WhatsApp bar visible the whole way down. Same information, radically different reachability.

I was optimising for a clean page. They were optimising for a phone call. Theirs was the correct objective.

Lesson two: write the scope down, even for small jobs

We agreed the work in conversation. Pages, a form, responsive layout. Obvious enough.

Then came reasonable-sounding additions: another college page, a tweak to the enquiry fields, a change to how the WhatsApp message is pre-filled. Each one small. Together, meaningful.

None of it was anyone behaving badly. It happened because nothing was written down, so there was no shared reference for what “done” meant. Now I write a short scope note before starting, even for a one-page site: what is included, what counts as a revision, and what is a new request. It makes additions a normal conversation instead of an awkward one.

Lesson three: build the handover before you need it

The site works, but the client cannot edit it. Every content change is a message to me. That was fine during the project and less fine three months later.

What I would do differently: keep editable text in one obvious place, write a short plain-language note on how to change common things, and confirm where the domain, hosting, and email credentials live while everyone still remembers.

Handover is not paperwork at the end. It is a design constraint from the start.

Lesson four: SEO is part of delivery

A local consultancy lives on being findable. Titles, meta descriptions, a sensible heading structure, real page names, and fast mobile loading are not extras on a project like this. They are the point. Building it fast and then bolting SEO on afterwards would have meant rewriting the markup.

What carried into the next project

• Put the primary action where the user already is, not where the layout is tidiest.
• Write scope down, however small the job.
• Plan the handover on day one.
• Treat performance and SEO as delivery requirements, not polish.

The technical skills transferred to the next client build. These four are the ones that actually changed how I work.