About
We are hiring a senior architect/lead to design and guide the delivery of a web platform that works alongside the Flutter app, uses the same Firebase backend (Auth/Firestore/Storage), and keeps our existing HTML blog pages and URLs unchanged. This role's primary mandate is to reduce technical risk and provide clear, implementable direction to our coders so the project ships correctly, securely, and with strong SEO foundations.
Key responsibilities
Architecture & routing: Define the target web architecture and URL/routing strategy so static HTML blog pages remain intact while new routes (e.g., profiles and forum) are introduced without collisions or regressions.
Rendering strategy for SEO: Specify the right server-rendering and/or pre-rendering approach so profile and forum pages load as complete HTML for crawlers, sharing previews, and strong desktop UX.
Firebase integration: Design how the web platform reads/writes data safely and efficiently (public vs authenticated content), including security/privacy boundaries, scalability, and cost/performance considerations.
Technical SEO leadership (implementation-focused): Own requirements for sitemap strategy (including high-volume UGC), metadata standards, canonical/duplicate-content controls, structured data where applicable, robots/indexation rules, pagination, and internal linking between blog profiles forum.
Direction to developers: Translate requirements into actionable implementation guidance (sequencing, tickets, acceptance criteria), review work for alignment, and support troubleshooting so the team can deliver confidently.
Cross-functional communication: Partner stakeholders to define what content is public vs private, align on rollout priorities, and communicate decisions, risks, and progress in a clear, non-technical way.
Delivery and rollout: Lead a phased rollout (start with highest-ROI page types, validate indexing and performance, then expand), with quality gates for SEO readiness, performance, and security.
Operational readiness: Define expectations for caching/revalidation, Core Web Vitals performance targets, staging vs production environments, and monitoring/alerting so the platform is reliable as it scales.
Success looks like
The blog remains unchanged and stable (URLs preserved, no SEO loss).
Profiles and forum become crawlable, indexable web URLs with correct metadata and sitemaps.
Technical risks are actively managed, and our coders can implement efficiently with clear direction and minimal rework.
Ideal background
Senior experience shipping platforms with SEO-sensitive pages.
Strong Firebase production experience and ability to turn architecture into clear developer instructions.
Demonstrated technical SEO engineering outcomes (not just content/keyword strategy) and the ability to communicate effectively with both technical and non-technical audiences.
Update based on feedback:
"As a senior developer and an honest person, I can tell you that with changes of this scope, especially when introducing a new rendering layer next to an existing site, zero risk does not exist. The goal is to keep risk controlled and reversible, and to avoid silent routing or SEO failures"
Phased rollout
I would not do a full switch. The app would be introduced only for a small, clearly scoped set of new routes. Everything else would continue to work as it does today. At the start, these routes can be restricted or marked noindex to validate routing and SSR behavior. Expansion would happen only after stable routing and clean indexation signals are confirmed.
Quality gates
Before expanding traffic, I would set clear go or no-go checks. These include no routing conflicts with existing HTML pages, correct server-rendered HTML, acceptable Core Web Vitals, correct meta and canonical tags, and strict separation of public and private data. If any of these fail, rollout stops.
Keeping the HTML blog unchanged
The existing static HTML blog would be treated as read-only and kept out of scope for There would be no catch-all routing or rewrites touching blog paths. Boundaries would be enforced at the hosting or edge level so the app cannot intercept blog traffic. I would verify this with basic crawling before and after deployments.
Testing before launch
Before anything goes live, routing and rendering would be validated in a staging environment close to production. This includes checking raw HTML output and confirming that unauthenticated users only see intended public content.
Technical SEO validation
Sitemaps would be split by content type and limited to approved public pages. Canonicals would be explicit to avoid duplication. After rollout, Search Console would be monitored for index coverage, duplicates, crawl errors, and performance, especially early on.
Monitoring and rollback
Monitoring would combine logs, performance metrics, and Search Console. Because rollout is scoped, rollback is straightforward: disable specific routes or routing rules without affecting the rest of the site.
Risks
The main risks are routing conflicts, accidental exposure of private data, SSR performance or cost issues, SEO duplication or canonical mistakes, and Firebase read costs from uncached SSR. These are manageable with clear boundaries, caching, and incremental rollout.
Communication
Weekly updates with progress, decisions, risks, and next steps are 200% reasonable. Anything that threatens the outcome should be raised immediately.
Week one requirements
In week one, I would need access to Firebase or a safe staging setup, an overview of the current URL structure and traffic priorities, a clear definition of public versus private content, and alignment on rollout priorities. Getting this right early reduces risk later.
Contract duration of 3 to 6 months. with 40 hours per week.
Mandatory skills: Technical SEO, React, JavaScript, Web Development, GitHub
Languages
- English
Notice for Users
This job comes from a TieTalent partner platform. Click "Apply Now" to submit your application directly on their site.