From my time at Zone01 Kisumu, one thing has become evident, "Every project builds the next". It is a gradual process which makes the learning experience worthwhile. The knowledge I built during the Ascii-art-Web assignment was the exact foundation that made building a real, working site almost effortless.
Throughout the ASCII-Art project, I thought of this idea for my production-grade project at Zone01 Kisumu. Building a mobile-responsive web platform for INKA LittUp, a full-service electrical outfit, to showcase their portfolio and convert site visitors to potential clients.
*The Mindset Shift: From In-Memory String Math to Asset Delivery
*
For INKA LittUp, the engineering challenge completely shifted. I wasn't parsing characters anymore, as in Ascii-Art-Web, I needed to serve static visual assets fast, enforce strict HTTP route boundaries, and ensure zero false 200 OK responses.
*Fixing Catch-All Routing in Go
*
An important lesson from the Ascii-Art project was defensive error handling. In Go, http.HandleFunc("/", ...) acts as a catch-all prefix match. If a user requests /some-random-url, Go’s default behavior will serve index.html with a 200 OK status code instead of a 404 Not Found.
For INKA LittUp, I had to enforce strict route checking;
_package main
import (
"fmt"
"log"
"net/http"
)
func main() {
fmt.Println("Server starting on http://localhost:8080")
// 1. Serve static assets cleanly (CSS, cover photos, gallery images)
// /static/styles.css maps directly and safely to ./static/styles.css
fs := http.FileServer(http.Dir("./static"))
http.Handle("/static/", http.StripPrefix("/static/", fs))
// 2. Strict root handler guard
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
if r.URL.Path != "/" {
http.NotFound(w, r) // Properly return 404 for bad paths
return
}
http.ServeFile(w, r, "index.html")
})
// 3. Start listener with crash-logging
err := http.ListenAndServe(":8080", nil)
if err != nil {
log.Fatal("Server failed to start:", err)
}
}
_
*Pragmatic Architecture: Value Over Complexity
*
Developing production-grade platforms showed me that great engineering is not about designing complex stack but about maximizing utility while keeping maintenance low. I customized the platform to use already existing APIs as follows:
- For the contact form, I used Formspree API Integration to ensure zero database overhead and instant email alerts.
- For direct messaging, WhatsApp Deep Link(wa.me) which ensures instant mobile contact on a platform clients already use.
*The Mobile Reality Check
*
During testing on mobile devices, I ran into this issue where the hero image was cropping awkwardly on narrower screens. Instead of throwing heavy JavaScript at the problem, adjusting the CSS container behavior fixed it cleanly:
/* Clean mobile background containment /
.hero {
background-size: contain;
background-color: #121212; / Dark background fill for extra space */
}
*Shipping to Production: Continuous Delivery on Render
*
For this particular platform, I turned the deployment mindset into a continuous delivery pipeline as follows:
Version Control: Modular layout tracked cleanly in Git (Tyclone81/LittUp).
Automated Deployments: Connected the GitHub repository directly to Render.
Zero-Touch Releases: Every git push origin main automatically triggers a fresh build and redeploy.
*What’s Next?
*
Moving from terminal utilities to production web deployments showed me how fast you can grow when you build continuously. I'm taking these learning directly into my next production implementations!
Live Platform: https://inkalittup.onrender.com/
GitHub Repository: Tyclone81/LittUp
How did you make the jump from your early utility projects to your first live production site? Let’s chat in the comments.
Top comments (0)