Overview
This post documents the development of a small, modern web application built incrementally over a series of focused weekends. The goal is not to showcase a finished product, but to illustrate how different development disciplines naturally surface as a project evolves—even at a modest scale.
All identifying details have been intentionally generalized. What follows is an honest, in-depth look at the technical progression, decisions, missteps, and learning moments encountered along the way.
Project Intent (Anonymized)
The application’s purpose is straightforward: publish structured data maintained by a non-technical user and expose it through a clean, publicly accessible website. Rather than introducing unnecessary complexity, the solution deliberately favors:
- Cloud-native, low-cost services
- Managed identity and least-privilege security
- Simple deployment pipelines
- Infrastructure that can grow gradually
This framing heavily influenced the architecture choices and the development pace.
High-Level Architecture
At a conceptual level, the system resolves into four layers:
- Manual Data Entry Layer – A managed SaaS list used as a lightweight datastore
- API Layer – A serverless API that reads data securely and returns JSON
- Hosting Layer – A static site platform for frontend delivery
- Delivery & Configuration Layer – Git-based CI/CD, environment variables, and DNS
What makes this interesting is not the architecture itself, but how each layer surfaced organically during development rather than being fully designed upfront.
Timeline-Based Development
The build unfolded across two short, clearly defined work sessions. Each weekend emphasized a different type of development.
Weekend 1 (≈ 2 Hours): Foundation – Site, Data Model, and Splash Page
Objective
The first session focused on establishing foundational viability rather than end-user features:
Stand up the core data location, prove content can be hosted publicly, and validate the deployment pipeline.
This meant addressing data, hosting, and visibility in parallel—without yet connecting them.
What Was Built
By the end of the first weekend, three critical foundations were in place:
- A managed SaaS site was provisioned to act as the long-term data entry location
- An initial structured list was designed to model the data domain
- A static web application successfully served an
index.htmlsplash page on a custom domain
Although nothing was connected yet, each layer was validated independently.
Site & List Development
A dedicated site was created to act as the system of record for manual data entry. Rather than introducing a traditional database early, a list-based approach was chosen for speed, governance, and maintainability.
During this first session:
- A new site was provisioned specifically for the project
- A primary list was created and iterated on
- Columns were defined to represent the real-world attributes being tracked
- Data types (text, choice, number, currency, date) were intentionally selected to support future querying
Even in this early step, design decisions mattered. A clean schema would later reduce API complexity and transformation logic.
Static Web Deployment
In parallel, the hosting layer was validated:
- A static hosting service was created and connected to a source repository
- A minimal
index.htmlsplash page and basic CSS were committed - Automated deployment executed successfully
- A custom domain was attached and secured with HTTPS
Reaching a live splash page served as proof that DNS, SSL, and CI/CD were all functioning correctly.
Development Types Surfaced
-
Site & List Design
Information modeling, column selection, schema cleanliness, and future-proofing for API access. -
Static Web Development
Authoring basic HTML/CSS, validating folder structure, and confirming asset delivery. -
DNS & Hosting Configuration
Registrar setup, DNS delegation, custom domain binding, and certificate issuance. -
CI/CD Fundamentals
Repository integration, automated builds, and deployment validation.
Key Insight
Weekend one demonstrated the value of separating concerns early. By validating data modeling, hosting, and deployment independently, later integration work was significantly easier—and failures could be isolated quickly.
Weekend 2 (≈ 3 Hours): API Integration and Troubleshooting
Objective
The second session shifted focus from visibility to functionality:
Expose structured list data through a serverless API endpoint.
This is where complexity increased—and where most learning occurred.
What Was Built
- A serverless API was added alongside the static site
- Secure, app-only authentication was configured
- The API successfully queried list data via a platform REST interface/SDK
- JSON data was returned from a public endpoint
The result was not yet a polished frontend, but a fully functioning backend pipeline.
Development Types Surfaced
1. Serverless API Development
- HTTP-triggered functions
- Route definition and folder conventions
- JSON serialization and error handling
2. Identity & Access Management
- Application registrations
- OAuth client credential flows
- Least-privilege, resource-scoped permissions
- Separation of runtime identity vs. administrative identity
This work alone consumed a meaningful portion of the session.
3. Platform API Consumption
- Site discovery and resolution
- List identification
- Field expansion and mapping
- Converting platform-native responses into clean JSON
4. Configuration Management
- Environment variables replacing hardcoded values
- Secure secret storage
- Understanding runtime configuration boundaries
5. DevOps & Deployment Debugging
Several issues required diagnosis and correction:
- Misconfigured environment variables that prevented runtime execution
- Authorization failures caused by permission mismatches
- Deployment failures due to malformed configuration files
- Tooling prerequisites (runtime versions, module requirements)
Each error uncovered a new dependency or assumption.
Key Insight
The API itself was straightforward. Most effort went into everything around it: permissions, configuration, tooling changes, and documentation mismatches. This is typical of cloud-native development and often underestimated.
Cumulative Development Disciplines Encountered
By the end of the second weekend, the project had already touched:
- Static frontend development
- Serverless backend development
- Cloud identity and security design
- SaaS platform integration
- CI/CD workflows
- DNS and custom domain management
- Secret handling and configuration hygiene
- Troubleshooting distributed systems
Notably, none of these areas were planned as isolated tasks—they surfaced naturally as requirements emerged.
Lessons Learned So Far
- Fast validation matters – A live splash page changes everything
- Identity is the hardest part – Permissions consume more time than code
- Tooling evolves quickly – Assumptions based on older documentation break
- Configuration errors mimic code bugs – Logs and diagnostics matter
- Small projects still deserve good security – Least privilege scales down just as well as up
What Comes Next
With the backend pipeline proven, the logical next step is a frontend MVP:
- JavaScript-based data fetching
- Basic tables and summary views
- Error and loading states
- Progressive enhancement rather than over-engineering
Importantly, future work now builds on a solid, validated foundation.
Final Thought
This project demonstrates how even a small, weekend-built application can quickly intersect with professional-grade development concerns. By embracing incremental progress and treating each blocker as a learning opportunity, meaningful systems can be built without large budgets—or large teams.