Sarolta engineering case study / active beta SaaS
PageConverter:
Modern pages in. Editable Elementor out.
Sarolta designed and developed an application that reconstructs modern HTML and CSS as maintainable WordPress and Elementor pages a designer can inspect, adjust, and publish.
The engineering problem
Turn any webpage into an Elementor editable page in WordPress.
The application Sarolta builtA conversion platform that reads a source page, recovers its intent, maps it to native Elementor structure, validates the document, and returns it for human finishing work.
AI could already produce polished HTML and CSS in minutes. The harder problem was preserving that work inside a live editorial system of Elementor containers, widgets, responsive settings, templates, and WordPress data.
Conversion was treated as a translation problem rather than a file import. Each part of the source must become an appropriate editable component, retain its behaviour across breakpoints, and remain safe for future changes.
Authorize every job
Account, connected site, plan, token balance, and callback destination are verified before execution.
Normalize the source
HTML, CSS, assets, hierarchy, and responsive rules become a controlled source document.
Combine rules with model reasoning
Deterministic mapping handles repeatable structure; model assistance addresses ambiguous meaning.
Validate the signed handoff
The Elementor document is checked, recorded, and returned through an authenticated callback.
The intended outcome
More creative range. More finished work. Less rebuilding.
5–15 days
The typical brief-to-completion cycle for a standard business site.
3–5 days
An assisted path that leaves more time for creative finishing work.
An editable Elementor starting point can be prepared in minutes, replacing days of manual reconstruction.
- Protect the design phase. Explore rapid concepts and existing pages without planning a manual rebuild first.
- Convert the selected direction. PageConverter reconstructs it as real Elementor containers and widgets.
- Keep the handoff familiar. Theme nuance, content, detail, and publishing remain in WordPress and Elementor.
- Return time to the design team. Recovered effort supports more variation and stronger finishing work.
The conversion spine
Deterministic where it should be. Model-assisted where interpretation matters.
A plausible model response is not treated as a finished page. Predictable parsing and normalization are combined with semantic interpretation, then the Elementor document is validated before it reaches the connected site.
The operating model
From source page to editable handoff.
Recover the source structure
HTML, CSS, assets, hierarchy, and responsive rules become a normalized source document.
Map with context
Rules handle repeatable patterns; model assistance resolves intent that markup cannot express.
Build native Elementor structure
The output is containers, widgets, and compatible document data—not one custom-code block.
Validate before delivery
Document integrity, responsive behaviour, and the return path to WordPress are checked.
How the system decides
Rules for structure. Models for meaning.
Predictable parsing and normalization recover the source. Model assistance is reserved for interpretation. The returned Elementor document is then validated before delivery.
Native output
Containers, headings, text, images, and layout settings remain inspectable in Elementor.
Human finishing work
Designers retain control of theme nuance, content, visual detail, review, and publishing.
Designer workflow remains central
A heading stays a Heading.
The conversion target is a structured page that behaves like an Elementor page should—not a screenshot, locked import, or visual approximation hidden in generic code.
Elementor is the destination, not an afterthought.
The delivered page keeps the editor, structure panel, and controls a designer expects to use.
Prepared before the human handoff
A conversion becomes an editable starting point in minutes, ready for finishing work.
A user can follow the result
The workflow keeps an attributable record from source page through delivery.
Platform architecture
Explicit boundaries around a customer-site write.
Commerce, application services, conversion execution, and WordPress delivery are separated so a conversion is traceable, authorized, and safe to return to a connected customer site.
Customer & commerce
WordPress + WooCommerce
Pricing, checkout, customer accounts, and provisioning sit on the commercial site.
- Manager plugin bridges purchase events
- Plans and token allowances
- Connected-site onboarding
Application & jobs
Fastify, Postgres, Redis, Temporal
The typed API owns accounts, sites, API keys, job state, token accounting, and durable workflow direction.
- Provider-agnostic routing
- Durable validation, retries, cancellation
- Append-only authorization ledger
Conversion & delivery
Authorized workers + WordPress plugin
Workers prepare and validate output; the customer plugin receives signed delivery and writes the Elementor document.
- Signed callback + per-job token
- Callback destination validation
- Elementor-native result storage
APIFastify services scale independently.
RecordPostgreSQL retains job and ledger truth.
WorkersCapacity follows queue depth and provider throughput.
ProvidersClaude, Gemini, Codex, and DeepSeek route at runtime, including through OpenRouter.
Zero-trust engineering discipline
Trust is NOT part of the conversion.
No caller, model response, callback, or destination is assumed safe. Every customer-site write must be authorized, scoped, validated, and evidenced.
Durable jobs
Every run has an owner and an outcome.
Each job carries its account, site, authorization state, token balance, provider choice, execution record, and terminal result.
Security boundaries
Delivery is signed, scoped, and checked.
Connection tokens, hashed API keys, HMAC callbacks, destination validation, and rate limits protect the route back to WordPress.
Evidence-driven delivery
The complete path requires evidence.
Docker provides isolated acceptance environments; installer-based delivery owns the real runtime, migrations, wiring, and plugins.
AI-assisted development lifecycle
A strict zero-trust pipeline for production application code.
Produce
Create the phase artifact against its approved boundary.
Adversarial review
Challenge completeness, ambiguity, risk, and evidence.
Remediate
Resolve accepted findings before the next gate.
1. Requirements
Define production goals, constraints, risks, ownership, and acceptance criteria.
2. Specification
Turn approved requirements into a precise, testable technical contract.
3. Tests / RED
Build failing tests that prove the required behaviour is absent.
4. Code / GREEN
Implement only against the specification and RED evidence.
5. Implementation review
Evaluate the whole system with fresh integration, security, and end-to-end evidence.
What the engineering decisions preserved
Design freedom before conversion. Real controls after it.
- Start with the design. AI-created or existing HTML and CSS can enter the workflow without a planned manual rebuild.
- Keep the work editable. The result contains real Elementor containers and widgets a designer can inspect and adjust.
- Finish where the client works. Theme nuance, content, visual detail, and publishing review stay in WordPress and Elementor.
Have a difficult workflow step?
Bring us the part that does not fit in a prompt.
Dependable tools can be built around the systems a team already uses.