From Parking Lot to Production: How I Built & Launched AL-NOOR with AI
From a Parking Lot to the Stage: How I Rebuilt and Launched AL-NOOR with AI
An ordinary website project became a practical lesson in vibe coding, GitHub, Cloudflare Workers, DNS, and the value of refusing to give up.
For almost an entire day, my website seemed to be sitting in a technical parking lot.
The new design was ready. The pages were complete. The chatbot was working. The project had passed its tests. GitHub was holding the source code, and Cloudflare was waiting to serve it.
Yet the domain would not cooperate.
DNS, the quiet system that tells the internet where a website lives, appeared to have its own personality. I changed settings, refreshed dashboards, checked records, opened new tabs, and asked for guidance. Nothing seemed to move.
Then the project took an unexpected turn.
I stopped trying to speak the language of servers and started explaining the problem in my own words. That was when the real journey began.
The website we wanted to build
The original Aap Ka Ustaad website contained valuable educational information, including courses, policies, contact details, multilingual content, official links, and a working AI chatbot.
The content mattered. The old visual presentation did not have to remain.
The goal was to rebuild it as a premium educational platform for AL-NOOR—a modern, trustworthy centre supporting multilingual learners with driving theory, Taxi and VTC examinations, Spanish-language learning, DELE, CCSE, and other educational preparation.
The new website needed to be:
- Modern and professional
- Easy to read
- Mobile-friendly
- Multilingual
- Accessible
- Search-engine friendly
- Fast and maintainable
- Honest about its services
- Careful with legal and educational claims
- Compatible with the existing chatbot
Most importantly, it had to preserve the truth of the original website without copying its old design.
We began with an audit, not a redesign
A common mistake in website rebuilding is to begin by changing colours, fonts, and layouts.
We did the opposite.
Before designing anything, the complete original repository was audited. Every page, image, contact number, external link, course detail, policy, language section, script, and chatbot dependency was recorded.
This audit helped us identify important facts:
- The website contained multilingual English, Spanish, and Urdu content.
- It offered information about several driving and examination-preparation courses.
- Two verified WhatsApp contacts were used.
- The official email address was info@aapkaustaad.com.
- The chatbot communicated with an existing backend and therefore had to be protected.
- Some educational and regulatory details were time-sensitive.
- Some promotional claims and learner images required careful verification.
- The original website did not have a secure server-side contact form.
This stage was not visually exciting, but it protected the entire project from a dangerous problem: building a beautiful website with incorrect information.
A modern architecture behind a human-looking website
The rebuilt platform was created with React, TypeScript, vinext, Vite, and a Cloudflare Worker runtime.
That may sound complicated, but the basic idea is simple.
React manages the website’s reusable interface. TypeScript helps detect programming mistakes. Vite and vinext prepare the application for production. Cloudflare Workers run the website close to visitors around the world.
Instead of maintaining dozens of unrelated HTML files, the new project uses shared components for elements such as:
- Navigation
- Footer
- Page structure
- Buttons
- Contact forms
- Language sections
- SEO metadata
- The AI chatbot
The website still preserves familiar addresses such as:
- /about.html
- /courses.html
- /contact.html
- /policies.html
- Individual course pages
This allows the new platform to feel modern without unnecessarily breaking existing links.
One page at a time
The project was deliberately not converted in one massive operation.
Each meaningful page was handled separately. The old page remained the factual reference, while the new page received its own information hierarchy and purpose-built design.
The homepage introduced AL-NOOR’s educational approach.
The About page explained the centre’s philosophy.
The Courses page organised verified preparation areas.
Individual course pages presented examination information carefully without inventing pass rates, guarantees, qualifications, or employment claims.
The Policies page used conservative language.
The Success Stories page avoided publishing unsupported statistics or learner material without documented consent.
The Contact page combined two WhatsApp contacts and email communication into one form.
After each meaningful task, the work stopped for review. Only after approval did the next task begin.
This slowed down careless changes but accelerated confidence.
Protecting the chatbot
The chatbot was treated as protected functionality.
It was already working on the original website, so rewriting it for style alone would have been risky. Its request format, backend connection, and response handling were preserved.
The new interface improved its appearance, responsiveness, keyboard behaviour, focus handling, and accessibility while keeping its core communication contract intact.
When the rebuilt site first appeared on its temporary workers.dev address, the chatbot answered correctly.
That small “Hola” bubble was more than a decorative feature. It was proof that the new architecture could preserve an existing integration without damaging the original production site.
GitHub: the source of truth
The completed project was placed in a new GitHub repository:
Navid-Ishaq/alnoor-aapkaustaad
At first, the rebuilt site lived on a development branch. The main branch still contained the earlier Coming Soon version.
The branches were checked carefully before anything was merged. The completed build was validated, the previous state remained recoverable through Git history, and the development branch was not deleted.
Eventually, the rebuilt project became the canonical version on the main branch.
GitHub was not the website’s runtime server. It became the trusted home of the source code. Cloudflare would automatically build and deploy new versions from it.
This separation is important:
- GitHub stores and tracks the code.
- Cloudflare builds and runs the website.
- DNS connects the domain to the correct service.
Meeting DNS—the gatekeeper of the internet
This was the part that turned the project into a story.
A domain name looks simple to a visitor, but several systems stand behind it.
The original domain, aapkaustaad.com, was registered at Namecheap and already served a static website through GitHub Pages. The new platform needed to appear only on:
alnoor.aapkaustaad.com
The original website had to remain working.
At first, it seemed that we could simply add a CNAME record at Namecheap. But Cloudflare could not fully connect the custom Worker domain because the main domain was not yet managed as a Cloudflare zone.
That was the moment DNS appeared to send us into the parking lot.
The solution was to move authoritative DNS management from Namecheap BasicDNS to Cloudflare nameservers while keeping Namecheap as the registrar.
Cloudflare provided two nameservers:
- bill.ns.cloudflare.com
- brenna.ns.cloudflare.com
Before switching, the existing DNS records were reviewed and imported:
- Four GitHub Pages A records for the root domain
- The www CNAME
- Five email-forwarding MX records
- The SPF record
- Google site-verification information
The root website records were kept as DNS-only records. This allowed aapkaustaad.com to continue reaching GitHub Pages while Cloudflare became the authoritative DNS manager.
The nameservers were then changed at Namecheap.
For a while, Cloudflare displayed a waiting message. DNS changes require propagation because nameserver information must spread across internet infrastructure.
Then, after a refresh, the message changed:
Your domain is now protected by Cloudflare.
The parking barrier had lifted.
Connecting the Worker to the custom subdomain
Once the Cloudflare zone became active, the remaining step was surprisingly quick.
The Worker’s Domains section was opened. The custom domain was entered:
alnoor.aapkaustaad.com
This time, Cloudflare recognised the parent zone immediately. It created the required connection and issued HTTPS support.
A few moments later, the rebuilt AL-NOOR website appeared on its final address.
After spending hours circling the parking lot, DNS did not merely point towards the stage—it held our hand and walked us onto it.
The contact-page lesson
After launch, two practical issues appeared on the Contact page.
First, clicking the visible email address opened a blank email window immediately. It would have been better to guide the visitor to the detailed form.
Second, the button labelled “Send securely by email” could not send because the production email-delivery service had not been configured with private server credentials.
This exposed an important principle: a website should never pretend that a message has been securely delivered when it has not.
Instead of hiding the limitation, the flow was redesigned.
Now:
- The upper email action takes the visitor to the contact form.
- The visitor enters their details once.
- Clicking the email button opens their email application.
- The recipient is filled automatically.
- The selected course becomes the email subject.
- The name, email, phone, city, language, course, and message appear in the email body.
- The visitor reviews the draft and presses Send.
The WhatsApp options continue to work with the same form data.
This solution requires no exposed password, API key, or insecure frontend trick. It is transparent about what happens.
The update was tested, pushed to GitHub, and automatically handed to Cloudflare—all while I remained on the “stage.”
Was this vibe coding?
Yes—but not in the careless sense sometimes associated with the term.
I did not write every line of TypeScript myself. I often explained technical problems in ordinary, freestyle language.
I said things such as:
“DNS has kept us circling the parking lot all day.”
Behind that sentence was a real technical problem involving nameservers, zone activation, DNS propagation, and custom-domain binding.
I described the result I wanted. I reviewed what appeared on the screen. I noticed when behaviour felt wrong. I approved one controlled task at a time.
The AI translated my intent into architecture, code, tests, Git operations, and deployment steps.
That is a genuine form of modern software creation.
The human does not disappear. The human becomes the director.
The AI may understand programming syntax, but it still needs someone to decide:
- What should be built?
- Which information is true?
- What experience should the visitor have?
- Which risks are acceptable?
- When is the result good enough?
- What must never be changed?
What I learned
This journey taught me several lessons.
Clear intent matters more than technical vocabulary
You do not always need the perfect technical term. You need to describe the problem, the desired outcome, and what must remain protected.
DNS is simple only after it works
A domain can involve a registrar, nameservers, DNS records, hosting services, SSL certificates, email records, and deployment platforms. Changing one part without understanding the others can interrupt a website or email.
Git history is a safety net
Keeping the previous website state in Git history meant that progress did not require destroying the past.
A successful build is not enough
The website also needed page checks, responsive testing, accessibility review, internal-link validation, chatbot verification, and factual restraint.
AI should not hide uncertainty
If secure email delivery is not configured, the correct approach is to say so or provide an honest alternative—not to display a false success message.
Freestyle communication can still produce structured work
My language was informal, but the decisions were real. A good AI collaborator can extract requirements from natural conversation without forcing the user to sound like a software engineer.
Final reflection
I began with an existing educational website and a clear wish: preserve its purpose, improve its presentation, and give it a stronger future.
The result was more than a redesign.
It became a lesson in controlled migration, modern web architecture, AI collaboration, GitHub workflows, Cloudflare Workers, DNS management, and practical problem-solving.
At times, the process felt technical. At other times, it felt like theatre.
I was sitting on the stage, describing what the audience should see. Behind the curtain, repositories changed, builds ran, records propagated, certificates appeared, and a new scene quietly moved into place.
Then the curtain opened.
AL-NOOR was live.
And perhaps that is the most exciting part of modern vibe coding: you may begin by speaking in your own ordinary words, but with the right collaboration, those words can become a real, tested, working product on the internet.
A Note for Readers
This article uses a few technical terms and friendly metaphors. Here is a simple explanation of each:
Websites mentioned
- Original website: https://aapkaustaad.com
The existing educational website, preserved and kept operational during the rebuild. - New AL-NOOR website: https://alnoor.aapkaustaad.com
The redesigned platform built with a modern architecture and hosted through Cloudflare.
Terms and expressions
- Parking lot: A humorous metaphor for the period when the project was technically ready but could not move forward because the domain connection was still unresolved.
- Stage: The live public website where visitors can finally see and use the completed work.
- Behind the curtain / Backstage: The code, tests, repositories, build processes, and configuration work that visitors do not normally see.
- DNS: The internet’s address system; it tells browsers which service or server should open when someone enters a domain name.
- DNS propagation: The time required for updated domain information to spread across internet networks worldwide.
- Domain: The human-readable address of a website, such as aapkaustaad.com.
- Subdomain: An additional address connected to a main domain, such as alnoor.aapkaustaad.com.
- Registrar: The company where a domain is registered and managed; in this project, that company is Namecheap.
- Nameservers: The services responsible for directing and managing a domain’s DNS records.
- DNS record: An individual instruction showing where a website, subdomain, email service, or verification request should go.
- A record: A DNS record that connects a domain to a numerical IP address.
- CNAME record: A DNS record that points one domain or subdomain towards another hostname.
- MX record: A DNS record that tells the internet where email for a domain should be delivered.
- GitHub: The platform used to store the website’s source code, preserve its history, and manage updates safely.
- Git history: A recoverable timeline of previous code versions, allowing earlier website states to be reviewed or restored.
- Branch: A separate line of development in Git, used to prepare and review changes without immediately replacing the main version.
- Main branch: The repository’s primary source branch, used by Cloudflare to build the production website.
- Commit: A recorded and identifiable set of changes made to the project.
- Cloudflare: The platform that builds, runs, protects, and delivers the new website to visitors.
- Cloudflare Worker: A lightweight application that runs the website through Cloudflare’s global network without requiring a traditional web server.
- Build: The automated process that converts source code into a production-ready website.
- Deployment: The process of publishing a completed build so that visitors can access it online.
- SSL/HTTPS: The security system that encrypts communication between a visitor’s browser and the website; it is represented by the padlock in the browser.
- Runtime: The environment in which the website’s application code operates after deployment.
- React: The technology used to create reusable and interactive parts of the website.
- TypeScript: A programming language that helps identify errors and makes JavaScript-based projects safer to maintain.
- API: A defined method through which one application communicates with another, such as the website communicating with the chatbot backend.
- Backend: The part of a digital service that works behind the scenes, processing requests and returning results.
- Chatbot integration: The connection between the visible AI assistant on the website and its existing backend service.
- Responsive design: A design approach that allows the website to work properly on mobiles, tablets, laptops, and large screens.
- Accessibility: Practices that make a website easier to use for people with different abilities, devices, and navigation methods.
- SEO: Search Engine Optimisation—techniques that help search engines understand and present a website correctly.
- Vibe coding: A collaborative way of creating software by describing goals and desired behaviour in natural language, reviewing the results, and allowing AI to translate that intent into working code.
- Guardrails: Safety measures such as approvals, testing, backups, factual checks, and protected integrations that prevent fast AI-assisted work from becoming careless.
The theatrical expressions in this article—such as the parking lot, stage, backstage, curtain, and DNS “holding our hand”—are storytelling metaphors. They describe real technical stages in a way that nontechnical readers can understand and enjoy.
Comments
Post a Comment