Sextant MVP: Leveraging AI to build a style app over Easter Weekend
A four-day AI-assisted MVP build of Sextant, a style app exploring signal calibration through software.
Introduction
I started experimenting with using AI assistants to provide style and fashion advice last year. I got excellent results, but the process required a lot of introspection and relied upon the user to ask the right questions. The idea to try and productise a more accessible version of this experience had been floating around in my head all winter, this culminated in outlining the philosophy underpinning the product in The Signal and the Self.
I chose the name 'Sextant' for the project some months ago. The sextant is an instrument used to measure distance to astronomical bodies and provide direction at sea, in popular use during the golden age of sale. Hence I envisaged Sextant as a non-coercive tool to help men navigate, only in the world of modern style and aesthetics.
As spring came I found myself exploring Devon in the UK. During the four day Easter bank holiday weekend I stayed in a converted chapel on the edge of Exmoor. With lambs being born in the field a stones throw from my laptop I undertook the project to get a working prototype in four days.
I heavily leveraged AI for both the planning and execution of this project. I used chatgpt for exploring ideas and design and I used windsurf for the implementation itself.
Day 1 - Friday - Scoping
The scoping was arguably the hardest task in the build. I had previously explored some ideas and nearly always came up with an increasingly widening feature set, including items such as: onboarding quizzes, garment ontologies, garment inventories, specific item recommendations, skin tone detection and outfit generation. These are all valid and desirable features but each one adds implementation load, cost and complexity to a product whose value has not yet been validated.
I forced myself to narrow the MVP down to the thinnest slice of functionality that was both bounded and evoked the value that I had experienced during self directed usage. I was aiming to find the smallest possible feature set that would provide signal. Chatgpt was extremely helpful as I used it to discuss different features, strategise and narrow scope.
I decided upon a single ‘photo upload’ -> ‘analysis’ flow. This preserved simplicity of implementation and delivered a feedback loop that preserved the engaging experience I had discovered during self-directed usage.
Day 2 - Saturday - Model and Backend
For production implementation I had some ideas around building detailed ontologies and using advanced computer vision techniques. However, for the purposes of getting to value and an MVP ASAP, I determined that I could build the analysis on top of an AI prompt.
I signed up for an openAI account and started using the API with the node sdk experimenting with different prompts and the outputs that they produced. I iterated and got a relatively stable output that I judged I could build the product on top of.
I settled for a model that looked like:
{
"style_signal": "Summary",
"coherence": "Represents how well items hang together: {low | medium | high},
"anchor": "Strongest item",
"friction": "Clashes",
"adjustments": "List of suggested improvements",
"preview_image_url": "base64 encoded image returned to frontend for display purposes"
}
For the backend I chose Express. The service only needed to perform a handful of tasks: accept an uploaded image, call the OpenAI API, and return a structured analysis response. Express is lightweight, well understood, and was more than capable of handling these requirements. More importantly, it allowed me to focus on the product rather than the infrastructure.
I constructed a single endpoint service accepting an image as input and returning analysis in the form of a structured json response. I built a library of test images representing different n-dimensional points in my model space. I scripted automated testing over the test image library against the backend to protect against regressions.
Day 3 - Sunday - Frontend
Now that I had a stable backend I switched my focus to building the frontend. The main goals were preserving the simplicity of the interaction loop and presenting the analysis in a comprehensible way.
For the frontend I kept the stack deliberately minimal: static HTML, CSS and vanilla JavaScript served directly from the Express app. The product did not need routing, state management, or a component framework, it needed simplicity. Serving the frontend from the same Express service also avoided unnecessary CORS and deployment complexity, keeping the application easy to reason about and fast to ship.
On the analysis page I opted for a card layout which would work well both on desktop and mobile. I ran my service through ngrok to provide a publicly available service, allowing testing on a mobile web browser, allowing me to tweak the appearance on mobile.
I added some polish in the form of a sextant logo and favicon. And I added some backstops such as per hour and per day rate limits to prevent abuse.
Day 4 - Monday - Production
On Monday I aimed to get my service into production and hosted on my custom domain sextantapp.io. I assessed the available options for hosting my web app. I chose Railway largely because it appeared to offer the shortest path from a local application to a publicly accessible product.
I asked Windsurf to configure the app for railway, connected the GitHub repository, configured the required environment variables, and had the application deployed and hosted on my custom domain within half an hour. DNS setup for my custom domain was handled automagically via cloudflare. For an MVP whose purpose was validation rather than scale, Railway removed a significant amount of operational friction. I added some logs, made sure errors surfaced correctly and I was done.
What I learned
The biggest surprise was that implementation was not the bottleneck. Once the scope was constrained and windsurf was leveraged then building the app was extremely straightforward. Windsurf being particularly effective when implementation tasks are tightly bounded.
Defining the judgement embedded within the product via the model and prompt proved substantially harder. While the first version uses a fairly simplistic model, the locus of future Sextant work lies in refining the underlying style model itself.
With a tight scope, leveraging Chatgpt for strategic discussion, Windsurf for implementation, and a minimal stack Sextant was born, alongside lambs over Easter.
You can use sextant now at sextantapp.io