April 2026
Proposal

Web Platform Development
Accessible Travel & Leisure Database

A structured, scalable platform designed for discoverability, accessibility, and long-term content management. Built from real systems, not templates.

This proposal is grounded in platforms I have already built: structured directories, filter-heavy search systems, map-led interfaces, and editor-friendly CMS tools that make large content libraries manageable over time.

5
Relevant Platforms
24+
Systems Built
3,000
Entry Scale Target
8–9
Weeks Estimated
Proposal — Page 2 of 5
About

I build platforms and the systems that keep them usable.

SSTIEM is a one-person studio focused on complete product systems: the public interface, the data architecture underneath it, and the operational tooling that allows a team to keep the platform accurate after launch. I do not work from themes or site builders. I build custom structures that match the shape of the problem, especially when content, filtering, and long-term maintainability matter.

For your travel and leisure database, that matters because this is not just a website. It is a living content product with thousands of entries, multiple filtering paths, editorial workflows, accessibility considerations, and a public experience that must stay coherent as the database grows. The strongest fit for this brief is not a visual designer alone or a backend engineer alone. It is someone who can design the system from both directions at once.

Record Logic
The destination record has to be strong enough to power listing views, map behaviour, search states, and detail pages without duplicating content across the platform.
Discovery Design
Category browsing, regional navigation, accessibility filters, and the map all need to work as one joined discovery system rather than separate interface features.
Editorial Reliability
Editors need structured forms, permissions, and clear update paths so the database stays trustworthy as more entries, regions, and contributors are added.

Those three decisions determine whether the platform still feels simple after the first thousand records. If the record model, the discovery logic, or the editorial workflow is weak, the public experience becomes harder to trust and the internal team inherits unnecessary manual work.

Brief Alignment

How each RFP requirement maps to proven capability

Your RequirementHow This Proposal Addresses It
3,000+ Entries PostgreSQL relational model with dedicated tables for entries, categories, regions, and attributes. Proven at directory scale in World of Doors (74+ auto-generated pages) and LeadGen (40+ modules processing multi-source records into one clean dataset).
Multi-Filter Search API-driven combinable filters with persistent, shareable state and sub-500ms response. Tradezyx proves this at 18 filter dimensions. The same architecture powers your category, geography, and accessibility filtering.
Interactive Map Leaflet or Mapbox with clustered markers, click-to-detail routing, and results synced to the list view. ATX Notary demonstrates this as the primary product surface, not a decorative add-on.
CMS & User Roles Structured editorial forms with field validation, tiered permissions, and preview workflows for non-technical teams. AVLUX proves this at 30+ content models across 4 user roles with clear editorial governance.
Scalability Architecture where growth means adding records and taxonomy, not redesigning pages. World of Doors generates 74+ pages from one clean data source without any manual page-building process.
Multilingual Content model structured to support locale-aware fields and language-specific routing from the data layer, so multilingual capacity activates without a platform rebuild or migration.
Platform Requirements

What this platform has to do from day one

A strong outcome here depends on more than launching a polished public interface. The platform has to support clear discovery for visitors, structured publishing for editors, and dependable system logic underneath both. If any one of those layers is weak, the product becomes harder to trust and harder to maintain as it grows.

Public Discovery
Search, filters, and map behaviour that stay intuitive
Visitors should be able to move between category browsing, geographic exploration, accessibility filters, and destination detail without losing context or restarting the journey.
Editorial Control
A CMS shaped around real destination data
Your team needs structured forms for place details, certifications, media, accessibility features, and status updates so content quality remains consistent across thousands of entries.
Shared Logic
One source of truth behind every public view
Listings, map markers, search states, and destination pages should all reflect the same record structure so the product feels coherent rather than stitched together.
Long-Term Scale
Growth without operational drag
As the database expands, growth should come from adding records, categories, and regions, not from redesigning pages or introducing one-off exceptions into the system.
SSTIEM sstiem.com
Proposal — Page 3 of 5
Portfolio

Relevant systems already in production

World of Doors
Scalable Directory Platform
A multi-city directory generating 74+ structured pages from a category and region model. New records create new public pages automatically, turning growth into a data operation rather than a design bottleneck.
Directories • Structured Content
ATX Notary Platform
Map-Driven Service Finder
An interactive Leaflet interface with filterable markers, profile routing, and a role-based admin panel. The map is not decorative; it is one of the primary ways the product is understood and used.
Maps • Filtering • Roles
AVLUX
Visual CMS Engine
A modular CMS with 30+ schema models, structured field types, drag-and-drop editing, and admin tooling designed so non-technical teams can confidently manage complex content.
CMS • Content Architecture
LeadGen Platform
Data Enrichment Pipeline
A record-processing engine that ingests from multiple sources, normalises data, resolves duplicates, and scores completeness before publishing clean entries for search and export.
Data • Quality • Scale
Tradezyx
Multi-Filter Analytics Platform
A 39+ microservice platform with combinable real-time filtering across structured datasets. Users can layer category, region, status, and feature filters with sub-500ms response while administrators control access, data views, and configuration.
Real-Time Filtering • Scalability • Access Control

Together, these projects cover the main demands of your brief: large-scale structured content, editorial workflows, geographic discovery, multi-filter search, and an admin experience that remains usable after launch. The proposal below is based on those working patterns rather than hypothetical capability claims.

Technical Approach

How I would build your platform

ComponentApproach
CMS Custom headless CMS shaped around the actual editorial job: destination records, accessibility features, location data, media, certifications, and supporting notes. Editors get clear structured forms rather than a generic page builder that invites inconsistency.
Data Model PostgreSQL schema with dedicated tables for entries, categories, regions, accessibility attributes, certifications, and related content. The goal is a relational structure that remains understandable and fast as the platform grows beyond the initial 3,000-entry target.
Filtering API-driven filtering that combines category, region, accessibility features, and keyword search without page reloads. Filter state stays shareable and persistent, which improves usability for members, staff, and public visitors alike.
Map Leaflet or Mapbox with clustered markers, click-to-detail routing, and results synced to the same logic as the list view. The map and directory behave like one product rather than two disconnected discovery tools.
Accessibility Semantic HTML, keyboard-first interaction patterns, screen reader support, clear focus states, and strong information hierarchy built into the system from the beginning rather than checked in at the end.

In practical terms, this means a platform that is easier to trust because the public experience, the editorial workflow, and the system architecture all reinforce the same goal: clear information, dependable records, and growth without operational clutter. The delivery sequence below follows that same logic.

Phase 1
Foundation
Weeks 1–2
Content model, taxonomy, accessibility needs, filter logic, and map behaviour defined before interface build begins.
Phase 2
Core Build
Weeks 3–5
CMS backend, API layer, search engine, entry templates, and role-based editorial workflow.
Phase 3
Interface
Weeks 6–7
Public UI, responsive behaviour, synced map/list views, and accessibility review across the main journeys.
Phase 4
Launch
Weeks 8–9
Testing, content import support, deployment, editor training, handover documentation, and launch stabilisation.
SSTIEM sstiem.com
Why I'm a Good Fit
Alignment
Proposal — Page 4 of 5
Understanding

This is not a website project. It is a structured information product.

Your brief describes a platform that has to do several things at once: store complex destination data, make it discoverable through multiple paths, support an editorial team that grows over time, and present everything with the kind of clarity that earns long-term trust. That combination is what makes this project interesting — and it is also what makes it difficult to get right without the right foundations.

I have built every part of this kind of system before — not in a single project, but across five separate platforms that each tested a different piece of the same puzzle. A large-scale structured directory. A map-led discovery system. An editorial CMS for non-technical teams. A data pipeline that cleans and scores incoming records. A filter system that handles complex search without breaking. Your brief brings all of those pieces together, and I understand how they connect because I have already built each one independently.

01
Structured Data at Scale
The foundation of this platform is the record model. If destination entries, categories, accessibility features, and regional taxonomy are not structured correctly from the start, every surface built on top becomes harder to trust and harder to maintain.
02
Editorial Usability
A CMS is only useful if the team actually wants to use it. I build editorial interfaces shaped around the real job — structured forms, clear workflows, field validation — not generic page builders that invite inconsistency at scale.
03
Discovery That Connects
Filtering, search, map, and category browsing should behave as one joined system. When a visitor moves between those paths, the experience should feel coherent — not like switching between disconnected features.
I do not approach this as someone who builds websites. I approach it as someone who builds the system that makes the platform trustworthy — the data model, the editorial workflow, and the public interface, designed as one connected product.
How I Work

A thinking partner, not just execution

Architecture First
I define the system shape early so content, search, and admin workflows are stable before visual polish takes over. Structural decisions made in week one determine whether the platform still feels clear in year two.
Independent & Accountable
I work autonomously, with visible progress. Regular checkpoints and working prototypes at each phase mean the project never disappears into a black box or drifts from your expectations.
Full Ownership for You
Hosting, code, data, and deployment remain yours. No proprietary lock-in, no hidden platform dependency. You own the product and can evolve it on your own terms.
Practical Delivery
I optimise for working software — clear editorial tools, dependable system logic, and a platform your team can keep using without developer dependency after handoff.

I work as a one-person studio because it means every architectural decision, every editorial interface choice, and every delivery milestone has the same person behind it. There is no handoff risk between what is planned and what gets built. That matters most on projects where the data model, the public interface, and the CMS have to reinforce each other — which is exactly what your brief requires.

I want to build something your team is proud of and your users actually rely on — not a short-term launch asset that becomes fragile once the content base expands.
If selected, I would approach this as a long-term destination information product from the first week of work. The strongest version of this platform is one where clarity, usability, and scalability are designed in from the beginning — not added later.
SSTIEM sstiem.com
Proposal — Page 5 of 5
Investment & Deliverables

Three approaches depending on depth, refinement, and future needs

This project is best approached as a structured platform build rather than a standard website. The complexity lies in the data architecture, filtering system, CMS usability, and long-term scalability. To keep things flexible, I have outlined three tiers.

Core Platform
$4,500 – $5,500
A complete, functional platform with all core requirements in place.
Deliverables
  • Structured content system (entries, categories, regions)
  • Multi-parameter filtering & basic search
  • Interactive map with location markers
  • Detail pages for each entry
  • CMS with admin/editor roles
  • Media and document upload support
  • Responsive layout (desktop, tablet, mobile)
  • Deployment and hosting setup
Recommended
Full Platform
$6,000 – $8,000
The best balance of functionality, usability, and long-term scalability.
Everything in Core, plus
  • Refined filtering UX & navigation structure
  • Map interaction synced with filters
  • Scalable architecture for ~3,000 entries
  • CMS workflows for non-technical users
  • Multilingual-ready structure
  • UI refinement & layout consistency
  • System optimisation for maintainability
Extended Platform
$8,500 – $10,000
Designed for long-term growth beyond the initial launch.
Everything in Full, plus
  • Advanced filtering interactions & enhanced UX
  • Map clustering & richer interactions
  • Content validation & structured data
  • Groundwork for ratings & reviews
  • Preparation for certification workflows
  • Community contribution readiness
  • Additional performance considerations
Ongoing Support
Hosting, infrastructure management, monitoring, bug fixes, and platform stability. Does not include new feature development.
$300 – $500 / mo
How the Project Runs

Four phases — each with a checkpoint before moving forward

Phase 1
Alignment & Discovery
Weeks 1 – 2
We define scope, priorities, and success criteria together. You review the proposed structure and confirm direction before any development begins.
Phase 2
Build & First Review
Weeks 3 – 5
Core functionality is developed and shared as a working prototype. You walk through the system, test workflows, and provide structured feedback.
Phase 3
Refinement & Feedback
Weeks 6 – 7
The platform is refined based on your input — UI, usability, editorial experience. A polished version is presented for look, feel, and interaction review.
Phase 4
Delivery & Handoff
Weeks 8 – 9
Final testing, deployment, CMS walkthrough, and documentation. A final review ensures everything is complete and aligned before handoff.
Payment Structure
30 – 50%
Upfront at project start
30 – 40%
After core system completion
Remaining
Upon final delivery
What to Expect
Communication
Regular check-ins throughout each phase. You will always know where the project stands, what is being worked on, and what is coming next.
Revisions
Minor revisions are included within each phase. Larger scope changes can be discussed and scoped separately so the timeline stays clear.
Collaboration
This is a partnership, not a handoff. Every phase includes a dedicated review so we stay aligned on priorities, direction, and quality.
The goal is to build a system that is clear, maintainable, scalable, and usable long-term — not something that only works at launch.
Thomas — SSTIEM — sstiem.com — sstiem.pro@gmail.com
SSTIEM sstiem.com