Everyone wants AI in their product right now. A skincare brand asks for an "AI skin analysis" feature, and the obvious answer is to integrate OpenAI or Google Cloud Vision and call it done. But sometimes the right answer is to say no to AI — at least at first. That was the core decision on the OsloGlow project: a Norwegian skincare clinic that wanted a WordPress WooCommerce rebuild with a personalised skin quiz recommendation engine. This post covers the full journey — from migrating a Next.js site to WordPress, through a difficult hosting and DNS saga, to the decision to build a rule-based logic engine before any AI feature, and why that decision was the right one for a conversion-critical e-commerce feature.

The Client and the Problem

Who They Were

OsloGlow (osloglow.no) is a professional skincare clinic based on Pilestredet in Oslo, Norway, offering advanced skin treatments, laser treatments, and body contouring. Luqman — already a client from the earlier AirCliniq WordPress migration — reached out after parting ways with the clinic's previous Norwegian developer, who had built the site on Next.js. The relationship had broken down, and Luqman wanted a single reliable point of contact going forward for all website changes, with WordPress as the foundation rather than Next.js.

What Was Needed

The brief had two phases. Phase 1 was a faithful recreation of the existing osloglow.no site — more than 15 pages — on WordPress, with a clean, editable backend so future content and pricing changes could be handled without developer dependency for every small edit. Phase 2, once the foundation was stable, was a much more ambitious feature: a personalised skin quiz that would analyse a customer's skin profile and recommend specific products from the clinic's ZO Skin Health and SkinCeuticals product lines, with a one-click "add full routine to cart" WooCommerce integration.

Migrating from Next.js to WordPress

Why the Client Wanted Off Next.js

The previous developer had built osloglow.no on Next.js — a modern JavaScript framework that, while technically capable, requires ongoing developer involvement for any content change. For a skincare clinic that needs to update prices, add new treatments, and publish new blog content regularly, a framework requiring custom code for every edit creates an unsustainable dependency on a single developer. Moving to WordPress gave the client a content management system the clinic team could eventually manage independently for simple updates, while still supporting custom development for advanced features.

The recreation was quoted at $480 for a full rebuild of all 15+ pages, structured for future extensibility — specifically built so that adding a webshop, booking system, or other features later would not require starting from scratch. This kind of future-proofed migration is core to my WordPress migration and rebuild services at CodeSyte.

The Vercel and DNS Hosting Saga

When a Domain Has Two Owners

Once the WordPress rebuild was ready for deployment, a significant hosting obstacle emerged. The osloglow.no domain's DNS A record was not pointing to One.com — it was pointing to Vercel, the hosting platform the previous Next.js developer had used. One.com's support team confirmed that the domain's hosting was effectively controlled by Vercel's deployment configuration, and recommended contacting Vercel directly to remove the connection. The client, however, had no relationship with Vercel — it was a platform the previous developer had set up and never formally handed over.

This created a genuinely difficult situation: the domain registrar (One.com) said the fix needed to happen on Vercel's side, but the client had no account access or contact with Vercel at all. This is a common and frustrating problem when a business changes web developers without a clean handover — hosting and deployment platforms set up by a previous developer can become orphaned, with no clear path to access or remove them. The resolution required working through One.com's support team repeatedly to trace the DNS configuration and find a path to repoint the A record correctly without needing direct Vercel access.

Time-Sensitive Pressure from Active Ad Campaigns

Compounding the technical difficulty, the client was running active paid ad campaigns during the migration window and was understandably concerned about downtime affecting ad performance and a newly restarted advertising account's algorithm learning phase. Clear, honest communication was maintained throughout — confirming that hosting troubleshooting could cause temporary downtime, advising the client to consider pausing ad spend during the highest-risk window, and providing realistic timelines for each stage of the DNS resolution process rather than overpromising.

The site was eventually successfully migrated and went live on the correct WordPress hosting. This kind of hosting and DNS troubleshooting — particularly when inheriting infrastructure from a previous developer relationship — is part of what I handle through my WordPress hosting and migration support services at CodeSyte.

Rule-Based vs AI — The Skin Quiz Decision

The Client's Original Ask: AI Skin Analysis

Once the core WordPress site was stable, the client's Phase 2 proposal was ambitious: an AI-powered skin analysis system where users upload a photo of their face and receive an automated analysis of redness, pigmentation, texture, and fine lines, processed through OpenAI or Google Cloud Vision, mapped to a personalised AM/PM skincare routine with WooCommerce product recommendations. The client's own proposal document scoped this at $1,400 with an 18 to 25 day timeline.

Why the Recommendation Was to Build Rule-Based First

The counter-proposal was deliberately different: build a rule-based intelligent engine first, not AI. The reasoning was laid out clearly in the proposal sent to the client. A rule-based system is faster and more stable, ensuring launch without unpredictable results. It gives full control over recommendations — critical for skincare accuracy and brand trust, since a wrong product recommendation in a medical-adjacent skincare context carries real reputational and even safety risk. It is conversion-optimised, since the exact products shown and their order can be fine-tuned deliberately rather than left to a model's inference. And it is easier to test and improve, since the logic can be adjusted based on real customer behaviour and feedback rather than requiring model retraining.

The specific risk with AI image analysis for skincare recommendations is inconsistency — the same skin condition photographed in different lighting, at different angles, or with different image quality can produce different AI assessments. For a system recommending specific, priced medical-grade skincare products, that inconsistency is a liability, not a feature. A rule-based system using explicit quiz inputs is deterministic: the same answers always produce the same recommendation, which is essential for both customer trust and for the clinic being able to stand behind every recommendation the system makes.

The Rule-Based System Architecture

The proposed and built system used a six-step multi-step quiz, mobile-optimised, processing inputs through a priority-based logic engine following the hierarchy: Sensitive → Acne → Pigmentation → Aging → Texture. This priority ordering matters clinically — a customer with both sensitive skin and pigmentation concerns needs the sensitivity addressed first in product selection, since aggressive pigmentation treatments can aggravate sensitive skin.

From the quiz inputs, the system builds a dynamic skin profile and generates a personalised skin summary, a morning (AM) routine, and an evening (PM) routine. Products are mapped directly to WooCommerce from the clinic's two brand lines — ZO Skin Health and SkinCeuticals — using a provided product list with highlighted pricing. The result page displays three to six recommended products with a one-click "Add full routine to cart" bundle action, built with AJAX for a smooth, no-reload WooCommerce integration. Routine ordering followed correct skincare layering convention — cleanser, treatment, SPF last — applied consistently as a system-wide rule rather than a one-off fix, so it would automatically cover future products added to the catalogue.

This kind of custom logic engine development integrated with WooCommerce is specialist work covered under my WordPress custom development and WooCommerce integration services at CodeSyte.

Phased Milestones and Independent QA Testing

The project was structured across multiple milestones: webshop setup with full product catalogue and categories ($800), the custom logic engine, skin profile generation, and WooCommerce product mapping ($800), and ongoing refinement. A separate PPC specialist working on the client's side conducted independent acceptance testing — running specific test cases from an agreed test sheet against the live environment, not just reviewing code logic in isolation. Issues identified through this testing, including a routine ordering bug affecting product layering sequence, were fixed as system-wide permanent rules rather than one-off patches, with confirmation video walkthroughs (via Loom) provided for each fix to demonstrate the corrected behaviour transparently.

The Result

What Was Delivered Across the Engagement

• Full WordPress recreation of the osloglow.no site, migrated from Next.js, 15+ pages
• DNS and hosting conflict with Vercel resolved, site live on correct WordPress hosting
• Norwegian-language content fully built out across treatments, pricing, and about pages
• Multiple new staff bio sections added to the Om Oss (About Us) page with full bios and photos
• Pricing table rebuilt and expanded with new treatments and products as they were added
• Meta Pixel integration for ad tracking, SMTP configuration for contact form delivery
• WooCommerce webshop built with ZO Skin Health and SkinCeuticals product catalogue
• Custom rule-based skin quiz engine — six-step multi-step quiz, priority logic, dynamic skin profile generation
• AM/PM personalised routine generation with correct skincare layering order
• One-click full routine add-to-cart WooCommerce bundle system
• Independent QA testing process with documented video confirmations of fixes
• Mobile responsiveness overhaul addressing text sizing, broken icon links, and spacing issues

Ongoing Relationship

The project has continued across multiple milestones over several months, with the client funding each phase as work was completed and reviewed — webshop setup, the logic engine and product mapping, and ongoing maintenance and content updates. This kind of structured, milestone-based long-term engagement reflects the trust built through the earlier AirCliniq migration and the careful, transparent approach taken throughout the OsloGlow hosting and development challenges.

Key Takeaway: When Not to Build With AI First

AI Is Not Always the Right First Version

The instinct to reach for AI when a client asks for "smart" or "personalised" features is understandable — it is what every competitor is building, and it sounds impressive in a proposal. But for a conversion-critical recommendation system selling specific, priced products, a rule-based system built on explicit business logic is often the stronger first version. It is deterministic, testable, debuggable, and fully controllable — qualities that matter enormously when the recommendations carry real commercial and even health-adjacent weight. AI image analysis remains a genuinely valuable Phase 2 enhancement once the rule-based foundation is proven and generating reliable conversions — exactly the phased approach recommended to OsloGlow.

A Clean Developer Handover Prevents Orphaned Infrastructure

The Vercel and DNS saga on this project happened entirely because a previous developer relationship ended without a clean handover of hosting and deployment access. Any business changing web developers should insist on a full access audit as part of the transition — domain registrar, DNS management, hosting account, deployment platform, and any third-party API keys or services connected to the site. Without this audit, infrastructure set up by a departed developer can become genuinely difficult to access or remove, as this project demonstrated.

Independent QA Testing Catches What Internal Testing Misses

Having a separate specialist — in this case the client's own PPC expert — run independent acceptance testing against a documented test sheet caught a routine ordering bug that affected the clinical accuracy of the skincare recommendations. Independent testing, conducted by someone other than the developer who built the feature, is a genuinely valuable QA layer for any conversion-critical or business-critical system. It is worth building into the process for any significant custom development project.

Final Thoughts

OsloGlow is one of the most technically and strategically interesting projects in this portfolio — a Next.js to WordPress migration complicated by orphaned hosting infrastructure, followed by a deliberate decision to build a rule-based recommendation engine instead of rushing to AI for a conversion-critical skincare feature. The result is a system that is fast, predictable, fully controllable by the clinic, and ready for an AI enhancement layer once the foundation has proven itself with real customers.

If you are building a personalised recommendation system, a quiz-based product matching engine, or migrating a site away from a framework that has become a developer dependency, that is exactly the kind of strategic and technical work I handle at CodeSyte. Explore my full WordPress, WooCommerce, and custom logic engine development services here, or get in touch directly and I will review your current setup before we agree on the right approach.