Family Move Fit: research, editorial work and a bilingual web product. Composition based on the public homepage.
Family Move Fit helps families understand everyday life and costs in their selected cities before moving abroad. The product brings together public-source research, content preparation and a bilingual website with request intake. The family makes the final decision about where to move.
My work spans the architecture of this ecosystem, development with AI agents, research and editorial workflows, frontend engineering, the intake backend and publishing tools. I designed how agents receive tasks, which sources they can use, who checks their output and what makes a change ready for acceptance.
Three Systems with Clear Responsibilities
I separated the ecosystem into three repositories. Relocation Search owns research material, sources, comparison conditions and Python tooling. Relocation Content prepares English and Russian articles, images and announcements. Relocation Intel contains the web product, backend, Blog Admin and publishing integrations.
These boundaries protect the meaning of the data. Website copy cannot become evidence for a research claim, and a prepared article is not a published article. Each system has its own inputs, outputs and handoff rules. A real importer consumes the Content package, while research findings do not automatically overwrite public copy.
Research Agents and Traceable Evidence
The research workflow starts with an exact question and a domain contract. The coordinator defines the operator's scope, sources and expected output. Prepared rows are frozen with source references, extraction locations, dates and relevant conditions. An independent verifier checks that exact revision; the coordinator retains responsibility for integration into the canonical document.
Separate Python tools check document structure, links and budget arithmetic. Original amounts and periods remain distinct from conversions, and missing values stay distinct from zero. A key engineering decision was to separate source verification from mechanical validation: a correct calculation cannot establish whether its inputs are reliable.
The documented research workflow separates source verification, mechanical checks and coordinator integration.
Editorial Work with Bounded Context
English and Russian writers receive separate frozen briefs and saved material in their own language. They author independent articles. Once discovery is complete, the editorial cycle uses those saved inputs; a writer cannot expand the research on its own.
The workflow specifies one independent Russian review and two sequential independent reviews of the same unchanged English revision. The second English reviewer does not read the first reviewer's findings. Text changes invalidate dependent reviews, and findings return to a revision loop. The owner reviews the complete article and image package at one acceptance point.
I moved repeatable work into tooling. Python synchronizes classification, geography and SEO metadata between the article and its handoff, and checks canonical paths and the required three PNG formats. These commands support the editorial process; meaning and reader value still require separate review.
Publishing the Version That Was Reviewed
The local Blog Admin imports articles, images and Telegram drafts by run ID. Repeating an import recognizes existing records and preserves local editorial changes. Import prepares local material; sending it to DEV and publishing to production are separate actions.
DEV review confirmation is tied to the hash of the saved article snapshot. If the article changes, the earlier confirmation no longer applies. This connects the publishing decision to the content that was actually reviewed. Saving a local Telegram correction and updating an already sent message are separate actions as well.
Separate native-language reviews lead to a complete package. In Blog Admin, publication approval is tied to the exact saved snapshot.
Frontend and Request Intake
The bilingual frontend uses Astro, TypeScript and SCSS, with shared design tokens, responsive sections and interactive flows. The form and Hono Worker share one request contract. The server validates the input and Turnstile response, detects duplicate submissions and stores the request in D1.
Email delivery uses an outbox, retries and signed Resend webhook events. An email failure does not undo a saved request. The public Blog uses separate D1/R2 data, isolated from intake and email records.
The implemented intake design stores the request before asynchronous email delivery. An accepted response confirms receipt, not acceptance of the order.
Engineering Process and Outcome
I organized development around source routing, specialist roles and bounded tasks with explicit write authority. Context, planning, code checks, language review and publication decisions have distinct responsibilities. Checks follow the changed surface, and the delivery configuration separates PR, DEV and production.
The result is a connected ecosystem with a live public website, research and editorial material, and implemented intake and publishing mechanisms. The central engineering work is keeping the application, data and agent workflows consistent. This case does not claim sales, traffic or measured time savings.
This experience is relevant to products that need AI-assisted development, traceable data, internal tools and a controlled path from a prepared change to publication.