Editorial over template
Each section uses a different rhythm rather than repeating the same card grid from top to bottom.
Project Case Study
Building
Building
VonticAI
Designing and evolving a personal technology platform for projects, AI experiments, technical writing, and documented learning.
01
The Problem
I needed more than a portfolio website.
Not every direction survived. Some ideas added complexity without adding clarity; others made the platform feel more like a corporate technology site than a place for exploration and learning. The useful lesson was simple: keep the architecture strong, keep the interface quiet, and let the work itself carry the story.
I wanted somewhere to document the transition from enterprise technology, data, and analytics into hands-on AI engineering. That meant the site itself needed to become part of the work: something I could design, build, operate, improve, and explain.
Foundation
VonticAI Phase 2
A production-verified editorial platform with projects, AI experiments, insights, and strong engineering foundations.
Evolution
Datopology
The same verified foundation, expanded around data, context, AI, intelligent systems, and learning in public.
02
Design Principles
Attention without visual noise.
The goal was not to make Datopology look like a generic developer portfolio or another AI startup template.
Technical visuals with purpose
Architecture and system diagrams explain the work rather than acting as decorative illustrations.
Restrained color
Navy, blue, white, and subtle pale backgrounds create hierarchy without turning every section into an accent block.
Responsive by design
Desktop structures deliberately transform into simpler vertical narratives on smaller screens.
03
Information Architecture
Organizing the platform around the work.
The primary navigation changed from a consulting structure to a system built around learning, evidence, and progression.
Home
Platform overview
→
Projects
What I’m building
→
AI Lab
What I’m testing
→
Insights
What I’m learning
→
About
Why the journey matters
04
System Architecture
Simple where possible. Serverless where useful.
Datopology does not need a continuously running application server for its current workload. Most of the platform can remain static while server-side functionality is introduced only where it provides concrete value.
Visitor
Browser
→
Cloudflare
Edge / Pages
→
Datopology
HTML / CSS / JS
Contact workflow
↓
Pages Function
Request handling
→
Turnstile
Verification
→
Resend
Email delivery
Security
Validation · Turnstile · Rate limiting · Security headers
05
Building the Interface
Start static. Earn complexity.
The site deliberately stays close to the browser platform: semantic HTML, shared CSS, and small amounts of JavaScript.
That keeps the implementation understandable while the content model is still evolving. A larger framework can be introduced later if repeated publishing workflows justify it.
HTML
Semantic page structure
CSS
Shared Phase 2 design system
JavaScript
Navigation + form interaction
Responsive
Desktop → tablet → mobile
06
Contact Workflow
Static frontend. Real backend behavior.
The contact page is static HTML, but form submission crosses into server-side logic only when needed.
01
Visitor submits form
→
02
Turnstile verification
→
03
Pages Function validates
→
04
Resend delivers email
→
05
Confirmation returned
Design decision
Keep secrets and email-delivery credentials out of frontend code. The browser sends only the request data and verification token; environment secrets remain server-side.
07
Deployment
Git becomes the deployment workflow.
The repository is connected to Cloudflare Pages, allowing site changes to move through a straightforward source-control workflow.
Local
Build & test
→
Git
Commit changes
→
GitHub
Source repository
→
Cloudflare
Automatic deployment
→
Production
datopology.com
08
What I Learned
The site became part of the learning.
Design systems matter early
Extracting the shared Phase 2 CSS made every additional page easier to build and maintain.
Responsive design changes meaning
Some desktop structures cannot simply shrink. Timelines, diagrams, and editorial layouts often need different mobile representations.
Security belongs in architecture
Verification, secrets, validation, headers, and request controls are system decisions—not polish added at the end.
Build only the complexity you need
A static-first architecture can still support meaningful server-side capabilities without becoming a full application stack.
Real browsers expose design flaws
Mockups are useful, but responsive QA at actual viewport sizes revealed the issues that mattered most.
Git checkpoints change how safely you iterate
Small commits provided reliable restore points while the visual system changed substantially.
09
What Comes Next
The platform should evolve with the work.
Phase 2 turns Datopology into the foundation. The next improvements should increasingly come from real projects, experiments, writing, and technical depth.
Project Status
Live, evolving, and intentionally unfinished.
Datopology will continue changing as the projects, experiments, and technical depth behind it grow.