Company site and lead engine

TSG ProAdvisor

Full-stack developer · TSG ProAdvisor · January 2021 – February 2022 · my first engineering job

The public site for a company that trains and mentors tax professionals, built to do more than describe the business. It captured leads straight into Zoho, took payments online, and let staff change pricing without a developer. It was the first production system I shipped.

Visit the site

Still the site I built, though others have maintained it since I left in 2022.

The TSG ProAdvisor About page
  • Self-servepricingStaff changed prices in Zoho and the site followed. No developer, no deploy.
  • Automaticlead captureForm submissions landed in Zoho directly instead of being re-typed by hand.
  • OnlinepaymentsSigning up stopped requiring a phone call or a bank transfer.

The problem

TSG ProAdvisor trains and mentors people building tax and accounting businesses. Almost everything about that business runs on trust: someone has to believe you can teach them a profession before they pay you to do it. The website is where that judgement gets made, and theirs was not carrying it.

Behind the site, the process was manual in three separate places. Enquiries arrived and someone re-typed them into the company’s systems, which is slow on a good day and lossy on a busy one. Prices were hard-coded, so every promotion or adjustment was a developer task and a deploy. And nothing could actually be bought on the site: signing up meant a phone call or a transfer.

Any one of those is survivable. Together they meant the company’s storefront could not sell, and the people running the company could not change it without me.

My role

I joined TSG ProAdvisor in January 2021 as a full-stack developer and spent just over a year there, working alongside a senior developer who set direction and reviewed what I wrote.

Inside that, the site and its integrations were mine to build: the Next.js frontend, the Express and PostgreSQL service behind it, and the Zoho integration that carried leads, pricing and payments.

I want to be accurate about the boundary. I did not build TSG’s learning platform, and the student and course numbers the company publishes are not mine to claim. I built the front door.

  • My first production system, learning the job while doing it
  • A senior reviewing me, so direction was not mine to set
  • Zoho as the system of record, with its API a fixed dependency
  • Non-technical stakeholders who changed their minds mid-build

Approach

Let Zoho stay the system of record

The company already ran on Zoho, and the temptation as a new developer is to rebuild what you can see rather than integrate with what already works. Leads, pricing and payments lived there and needed to keep living there, because the people using them every day were not going to move. The site’s job was to be a front end to that, not a second source of truth competing with it.

A backend of my own, so credentials never reached the browser

The site talks to Zoho through an Express service rather than from the browser directly. That keeps API credentials on the server where they belong, and it gave me one place to validate, reshape and log everything crossing the boundary instead of scattering that through the frontend.

Pricing as data, not as code

Prices had been hard-coded, which made a developer the bottleneck on a routine business decision. Moving pricing into Zoho and having the pages read from it meant staff could run a promotion on a Tuesday without asking anyone. That is the part I liked best, because it took me out of a loop I should never have been in.

Treat a dropped lead as the worst outcome

A form that fails quietly is a customer the company never learns it lost. Submissions had to be validated before they went anywhere and confirmed as landed in Zoho rather than assumed, so a failure surfaced instead of disappearing.

What was hard

Not knowing how to do any of it yet

The honest hardest part was that this was my first real job. The framework, the API, the deploy: every piece was something I was learning while a business waited on it. I got most of it right, and I also spent longer stuck than I needed to, because asking for help felt like admitting I should not have been given the work. The senior reviewing me was sitting right there the whole time.

A vendor API I had to take as given

Zoho was the constraint I could not engineer around. Its shape, its behaviour and its availability were fixed, and the integration had to be correct against a system whose documentation and actual responses did not always agree. Most of the real work on this project was at that boundary rather than in the site itself.

Requirements that moved

What the site needed to do changed while I was building it, and my instinct then was to absorb each change quietly rather than ask what the underlying decision actually was. That cost rework a single direct question would have prevented.

Results

The site shipped and became the company’s front door, and it is still the site TSG runs on today.

Three manual processes stopped being manual: pricing, lead capture, and payment. I don’t have conversion or revenue figures for any of it. I was shipping features, not measuring business outcomes. And the student and course counts TSG publishes belong to their learning platform, which I did not build.

What I’d do differently

  • Ask for help sooner. I treated being stuck as something to hide rather than something to report. There was a senior developer assigned to review me who would have unblocked me in minutes. Wanting to prove myself cost more time than admitting confusion ever would have.
  • Force the requirement before building. When stakeholders changed direction, I rebuilt. I didn’t know yet that the useful move is making them decide out loud before you write the code.
  • Not trust the vendor API to behave. I wrote the integration assuming Zoho would answer, answer quickly, and answer in the shape I expected. Designing for it being slow, down, or different is what I would build in from the start now.
  • Write tests instead of clicking through. I verified the lead and payment flows by hand, every time. That works until the day you’re tired or in a hurry, and on a path where a silent failure is a lost customer, attention is exactly the wrong thing to depend on.

Stack

  • Next.js
  • React
  • Express.js
  • PostgreSQL
  • Zoho API