Building the Full Website Around the Product

    A web app is one thing.
    A full website is another.

    Once the core product worked, I needed the rest of the experience to feel like a real product,
    not a prototype that escaped the lab.

    That meant building the site around the app itself:

    - a clearer landing page
    - a more structured product narrative
    - a checkout / launch-access flow
    - explanatory docs
    - better routing and navigation
    - a layout that looks like something people can trust

    This is where product thinking starts sneaking into engineering.
    You are no longer only asking "does it work?"
    You are asking "does it feel understandable?"

    I wanted the site to explain the value of Archimedes without making people decode the interface.
    The message is simple:

    Archimedes helps you search academic papers, analyze them with an LLM,
    synthesize evidence, and export the result as a PDF.

    Everything else exists to support that.

    The site also helped me add the rough edges that early users expect:

    - a demo path
    - launch-interest capture
    - BYOK verification
    - a subscription-shaped access flow

    It is not about pretending the product is finished.
    It is about making the current version feel coherent.

    That coherence matters a lot when a project moves from personal tool to public product.
    The site becomes part of the trust layer.
    If the website feels chaotic, the product feels chaotic.
    If the website feels focused, the product feels more real.

    This was the stage where Archimedes started looking like something I could actually launch,
    instead of just something I hacked together for my own use.

Lately I started taking a design thinking course at my university, and it completely shifted how I approach Archimedes. Before, I was focused on building features that felt cool as a developer—fancier LLM prompts, faster search pipelines, shinier CLI flags. The course forced me to step back and ask: What problem am I actually solving? Through empathy mapping and problem‑statement workshops, I realized the real pain point isn’t just "research is tedious"; it’s that researchers lose the thread between scattered papers and their own hypotheses. Design thinking gave me a structured way to define the problem and solution from the user’s perspective first, then figure out the technology that fits. Suddenly the question became: How might we help a researcher go from a vague idea to a concrete, evidence‑based answer without leaving their workflow? That mindset made me prioritize user‑centric flows—like a guided question‑builder, one‑click evidence export, and a plain‑language report—over developer‑centric tweaks. The pipeline still does the same heavy lifting, but now it’s wrapped in a experience that actually listens to the person using it.

Lately I started taking a design thinking course at my university, and it completely shifted how I approach Archimedes. Before, I was focused on building features that felt cool as a developer—fancier LLM prompts, faster search pipelines, shinier CLI flags. The course forced me to step back and ask: What problem am I actually solving? Through empathy mapping and problem‑statement workshops, I realized the real pain point isn’t just "research is tedious"; it’s that researchers lose the thread between scattered papers and their own hypotheses. Design thinking gave me a structured way to define the problem and solution from the user’s perspective first, then figure out the technology that fits. Suddenly the question became: How might we help a researcher go from a vague idea to a concrete, evidence‑based answer without leaving their workflow? That mindset made me prioritize user‑centric flows—like a guided question‑builder, one‑click evidence export, and a plain‑language report—over developer‑centric tweaks. The pipeline still does the same heavy lifting, but now it’s wrapped in a experience that actually listens to the person using it.