Web Development / Security Engineering
Industry: Insurance
23
commits shipped across a ~3-week build (June 10 – July 2, 2026)
In short
Arcetis built a real, full-stack Node.js/Express web application for an insurance brokerage, not a template dump, centered on a self-hosted, single-admin CMS with bcrypt-hashed authentication, CSRF-protected sessions, rate limiting, and hardened security headers, all deployed through an automated GitHub Actions pipeline. The build shipped in roughly three weeks (23 commits) and covers 7 core pages plus 11 individual service pages, with every text block, image, and business detail editable by non-technical staff. Security was formally tested and documented in a written SECURITY-AUDIT.md, and the front end pairs a licensed Bootstrap template foundation with a fully custom design system rather than a stock look.
The client is a financial-services insurance brokerage offering a wide range of protection and wealth-planning products: life insurance, critical illness and disability coverage, mortgage protection, RESP and TFSA/RRSP planning, FHSA savings, retirement planning, wealth management, estate and legacy planning, and business insurance solutions. Rather than a single-service brochure site, the brokerage needed a website architecture that could represent eleven distinct product lines clearly, stay current without ongoing developer involvement, and hold up to the scrutiny reasonably expected of a financial-services business handling client inquiries. Arcetis was engaged to design and build that platform end to end: a real backend application with its own authentication, its own content management system, and its own deployment pipeline, rather than a page builder or a rented SaaS CMS. The engagement covered engineering, security, and the refinement of the site's visual design system.
Insurance brokerages sit in an unusual position online: they need to look established and trustworthy, they publish detailed product content across many distinct service lines, and they are expected, implicitly if not by formal regulation, to handle client data and inbound inquiries with real security discipline. That combination created several concrete constraints for this build. First, content volume and structure. Eleven separate insurance service pages, Life Insurance, Critical Illness Insurance, Disability Insurance, Mortgage Protection, RESP/Education Savings, TFSA & RRSP, FHSA/First Home Savings, Retirement Planning, Wealth Management, Estate & Legacy Planning, and Business Insurance Solutions, plus a Services index, Home, About, Contact, Privacy, and Terms pages, meant the client would be maintaining dozens of interdependent content blocks and images over time. A brochure site with hard-coded copy would have made every update, a new phone number, a revised product description, a swapped photo, a developer request. That was not sustainable for a small brokerage. Second, ownership and cost. A subscription CMS would have introduced recurring fees, third-party dependency, and a plugin attack surface the client did not need for a site of this scope. The brokerage's existing hosting was Hostinger's Node.js hosting, not a platform-as-a-service with built-in CI/CD, so any automation had to be built rather than assumed. Third, security expectations. A financial-services-adjacent business collects contact-form submissions that may reference sensitive personal and financial circumstances, and its admin dashboard is a single point of failure if compromised. That ruled out a casual approach to authentication or session handling; the site needed real password hashing, real session protection, real CSRF defenses, and rate limiting on the endpoints most likely to be targeted, login and contact, plus a way to demonstrate, not just assert, that those controls worked. Finally, timeline and budget realism meant the visual design could not be built from a blank canvas in three weeks without inflating cost disproportionately to a template-based approach, but a stock template alone would not meet the security, CMS, or SEO requirements above. The challenge was reconciling all four constraints in a single, coherent, three-week build.
Arcetis acted as the sole engineering partner for the build, owning architecture, backend development, security implementation, and deployment from the first commit. Arcetis designed the CMS data model and admin dashboard, implemented authentication and session security, wrote and enforced the CSRF and rate-limiting controls, configured Helmet's security headers, and authored the project's SECURITY-AUDIT.md documenting each tested control. Arcetis also built and hardened the GitHub Actions CI/CD pipeline, resolving several rounds of flaky SSH/host behavior against the client's Hostinger environment until deploys were reliable on every push. On the front end, Arcetis took ownership of the licensed Bootstrap template foundation and layered a custom design system on top of it, the "Warm Trust" gold-and-navy palette, Fraunces and Inter typography, a custom hero carousel, testimonial cards, and mobile-specific fixes, rather than shipping the template unmodified.
Arcetis built a single-admin CMS from scratch rather than integrating a third-party platform. Content lives in an atomically-written JSON store, edited through an admin dashboard that covers every text block across roughly 34 fields per service page, image swapping for each content slot, and site-wide business information, name, phone, email, address, social links, all without a database server or recurring SaaS fees, and without exposing the client to a large third-party plugin ecosystem's attack surface.
Admin access is protected by bcryptjs password hashing at cost factor 12, express-session with a file-backed session store, and csrf-csrf tokens enforced on every state-changing admin API call. Login attempts and the public contact form are both protected by express-rate-limit, and Helmet applies a Content Security Policy, HSTS, and frame-options headers across the site, a security posture built for a single point of administrative access rather than assumed away.
Beyond individual controls, Arcetis hardened the application against prototype pollution through input whitelisting and type coercion, and enforced path-traversal protection on file uploads. Every control was tested and written up in a formal SECURITY-AUDIT.md: unauthenticated admin API calls correctly return 401s, CSRF protection is verified end to end, output is escaped against XSS, and upload paths are checked against traversal, turning security claims into a documented, reproducible audit trail.
Arcetis built a GitHub Actions pipeline that validates every push and automatically deploys to the client's Hostinger Node.js hosting via rsync over SSH. Because Hostinger does not provide the push-to-deploy tooling of a platform like Vercel, this required custom scripting rather than configuration, including several dedicated commits to harden flaky SSH and host-key behavior until deploys ran reliably on every merge, without manual server access.
Each page receives server-side-injected canonical, Open Graph, and Twitter meta tags, and the site publishes FinancialService JSON-LD structured data along with a dynamically generated sitemap and robots.txt. For a brokerage marketing eleven distinct product lines, this gives search engines and AI answer engines a clear, machine-readable map of what the business offers and where, without relying on a plugin to generate it.
Rather than treat the front end as a finished asset, Arcetis refined a licensed finance/insurance Bootstrap template into a custom "Warm Trust" gold-and-navy visual system with Fraunces and Inter typography, a custom hero carousel, redesigned testimonial cards, and mobile-specific layout fixes, engineering effort layered on top of the template rather than a from-scratch visual design.
The build is a real Node.js/Express application, not a static export or a hosted builder configuration, and the implementation reflects that at every layer. Content and CMS architecture. Rather than reach for WordPress or a headless CMS SaaS, Arcetis built a purpose-specific content store: a single JSON file written atomically on every save, so a crash or concurrent write cannot corrupt the site's content. The admin dashboard built on top of that store exposes every text block across the Home, About, Services index, and all 11 individual service pages, roughly 34 independently editable fields per service page, plus per-slot image swapping and a single place to manage site-wide business information, name, phone, email, address, and social links. A message inbox rounds out the CMS: contact-form submissions arrive as read/unread messages the admin can reply to or delete, without a separate email-marketing tool. Authentication and session security. Admin login is protected by bcryptjs at cost factor 12, a deliberately expensive hashing cost chosen to resist brute-force and offline cracking attempts against a single admin account, which is the entire attack surface for content control. Sessions are managed with express-session backed by a file store, appropriate for a single-admin system on shared hosting, where a Redis or database session store would be over-engineering. Every state-changing admin API call, saving content, uploading an image, replying to a message, is protected by a csrf-csrf token, so an attacker cannot forge requests using a logged-in admin's browser. Rate limiting and headers. express-rate-limit is applied specifically to the login endpoint and the public contact form, the two endpoints most exposed to automated abuse, credential stuffing and spam submission respectively. Helmet adds a Content Security Policy, HSTS, and frame-options headers across the whole application, reducing the site's exposure to XSS, clickjacking, and protocol downgrade attacks by default rather than by exception. Input handling. Arcetis added explicit input whitelisting and type coercion on top of the JSON content model specifically to block prototype-pollution attacks, a class of vulnerability that is easy to overlook in JSON-driven Node applications and easy to exploit if overlooked. File uploads are checked against path traversal so an uploaded filename cannot be crafted to write outside its intended directory. Verification. Rather than assert these controls work, Arcetis documented and tested them in a written SECURITY-AUDIT.md, confirming that unauthenticated calls to admin API routes return 401, that CSRF tokens are actually enforced and not just present, that all dynamic output is escaped against XSS, and that upload paths are validated against traversal attempts. SEO and deployment. On the front end, each page injects its own canonical URL, Open Graph tags, and Twitter card meta server-side, and the site publishes FinancialService JSON-LD schema plus a dynamically generated sitemap and robots.txt, giving search engines and increasingly AI answer engines a structured, per-page understanding of an eleven-product-line business. Getting the application live and staying live was itself an engineering problem: Arcetis built a GitHub Actions workflow that validates every push and deploys via rsync over SSH to the client's Hostinger Node.js hosting, and spent several commits specifically hardening flaky SSH and host-key handshake behavior so that deploys succeeded consistently rather than intermittently.
Rather than treating security as a checklist, Arcetis built each control, bcrypt cost-12 hashing, CSRF tokens on all admin mutations, rate limiting on login and contact endpoints, Helmet's CSP/HSTS headers, prototype-pollution-safe input handling, and path-traversal-safe uploads, and then wrote a SECURITY-AUDIT.md proving each one holds under test: 401s on unauthenticated admin calls, verified CSRF enforcement, XSS-safe output escaping, and validated upload paths. Security became a documented artifact, not a claim.
The front end was not designed from a blank canvas: it started from a licensed commercial finance/insurance Bootstrap template. Arcetis's contribution was the engineering layered on top, the CMS, the authentication and security model, the CI/CD pipeline, and a genuinely custom design system, a "Warm Trust" gold-and-navy palette, Fraunces and Inter typography, a custom hero carousel, testimonial cards, and mobile fixes, built over that foundation. This is disclosed as refined-template work, not bespoke visual design from scratch.
Instead of integrating a general-purpose CMS built for many tenants and plugins, Arcetis built a content system scoped precisely to this brokerage's needs: an atomically-written JSON store, a single admin identity, roughly 34 editable fields per service page, image-slot swapping, and a contact-message inbox. That precision kept the attack surface small and the editing experience simple for exactly the one non-technical user who needed it.
Hostinger's Node.js hosting does not offer push-to-deploy the way Vercel or Heroku do, so Arcetis built that capability rather than assume it: a GitHub Actions pipeline that validates every push and deploys over rsync/SSH. Several commits were dedicated specifically to hardening flaky SSH and host-key behavior, reflecting the reality that automating deployment to conventional shared/VPS hosting takes real engineering, not just a YAML file.
Canonical URLs, Open Graph and Twitter meta tags, and FinancialService JSON-LD are injected server-side per page rather than bolted on with a plugin, alongside a dynamically generated sitemap and robots.txt. For a brokerage with eleven distinct service lines, that gives every product page its own accurate, structured signal to search engines and AI answer engines, instead of one generic template tag set repeated across pages.
commits shipped across a ~3-week build (June 10 – July 2, 2026)
individual insurance service pages, each driven by the custom CMS
Technology used
Key learnings
This build reinforced a distinction Arcetis treats as central to client work: the difference between a website that looks finished and an application that is actually engineered. A finance/insurance Bootstrap template can produce a polished-looking brokerage site in a day; it cannot produce a CMS a non-technical admin can safely operate, an authentication layer resistant to credential attacks, or a deployment pipeline that survives a flaky SSH handshake. Those had to be built, not configured. For a financial-services-adjacent business specifically, security work is not optional polish, it is the difference between a contact form and a liability. Building bcrypt hashing, CSRF enforcement, rate limiting, and prototype-pollution-safe input handling into the application from the start, and then proving each control in a written audit, meant the client received something that could withstand real scrutiny, not just an assurance that it was secure. The CI/CD work was a reminder that conventional shared/VPS hosting, as opposed to a modern platform-as-a-service, still requires real automation engineering: rsync-over-SSH deploys are not push-button, and getting them reliable took iteration, not a single workflow file. Finally, being transparent about the template foundation, rather than presenting refined template work as bespoke visual design, is itself a trust-building choice, consistent with the honesty the security audit itself models: state precisely what was built, and let the engineering speak for itself.
No. Arcetis built a self-hosted, single-admin content management system from scratch, a Node.js/Express application with content stored in an atomically-written JSON file, rather than integrating WordPress, a page builder, or a SaaS CMS. This avoids recurring subscription costs and the larger attack surface of a general-purpose, plugin-driven CMS.
Passwords are hashed with bcryptjs at cost factor 12, sessions are managed with express-session backed by a file store, and every state-changing admin request is protected by a csrf-csrf token. Login attempts are also rate-limited with express-rate-limit, and the results were tested and documented in a written SECURITY-AUDIT.md rather than simply asserted.
No, and Arcetis is explicit about that: the front end started from a licensed commercial finance/insurance Bootstrap template. What is custom is everything layered on top of it, the CMS, the authentication and security architecture, the CI/CD pipeline, and a bespoke "Warm Trust" gold-and-navy design system with custom typography, a custom hero carousel, and redesigned components, rather than the base visual layout itself.
Changes are saved through the CMS's CSRF-protected admin API into the atomic JSON content store, and application code changes are deployed through a GitHub Actions pipeline that validates every push and automatically deploys via rsync over SSH to the client's Hostinger Node.js hosting, no manual server access or FTP required.