Forem: Harshal Rudra

Building the Full Website Around the Product

Harshal Rudra — Sat, 18 Apr 2026 05:58:09 +0000

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 a personal tool to a public product.

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 something I hacked together for my own use.

When Design Thinking Crashes Into Engineering

Lately, I started taking a design thinking course at my university, and it completely shifted how I approach Archimedes.

Before that, 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 a much more uncomfortable question:

What problem am I actually solving?

Through empathy mapping and problem-statement workshops, I realized the real pain point isn’t just that research is tedious. It’s that researchers lose the thread between scattered papers and their own hypotheses.

That’s the gap.

Design thinking gave me a structured way to define the problem from the user’s perspective first, and only then figure out the technology that fits.

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 shift changed what I prioritized.

Instead of developer-centric tweaks, I started focusing on user-centric flows:

a guided question builder
one-click evidence export
a plain-language report

The pipeline still does the same heavy lifting.

But now it’s wrapped in an experience that actually listens to the person using it.

Building the Full Website Around the Product

Harshal Rudra — Sat, 18 Apr 2026 05:52:56 +0000

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.

From CLI to Web App: Making Archimedes Usable

Harshal Rudra — Fri, 17 Apr 2026 12:59:25 +0000

From CLI to Web App: Making Archimedes Usable

Once the CLI proved the workflow, the next question was obvious:
how do I make this usable for people who are not me?

The answer was a web app.

A CLI is great for power users.
A web app is better when the goal is to reduce friction.
If someone wants to type a research question, watch progress, and get a result without learning commands,
the browser wins.

So Archimedes moved into a web-based experience.

The web version gave me a better way to handle the full user flow:

enter keywords and a question
optionally upload a file
choose paper sources
set the paper count
start the analysis
stream progress back to the UI
review the final report
download a PDF

That transition changed the feel of the project.
It was no longer just a tool I used.
It was something other people could understand at a glance.

I built the app with a modern stack:

Next.js
React
TypeScript
Tailwind CSS
an LLM API for analysis

The important part was not the stack, though.
The important part was that the interface finally matched the workflow.

I also added a few product-ish pieces that made the app feel real:

a launch-access flow
a BYOK unlock path for users who want to bring their own model key
lead capture for people who are interested but not ready to pay
PDF export so the output is something you can actually keep

The web app was the point where Archimedes stopped being a personal experiment
and started looking like a thing someone could actually use.

When Friends Started Asking for It, I Knew It Wasn't Just for Me

Harshal Rudra — Wed, 15 Apr 2026 09:51:34 +0000

When Friends Started Asking for It, I Knew It Wasn't Just for Me

The weirdest part of building something personal is when other people want it.

I originally built Archimedes for myself.
It was my fix for a research workflow that felt too fragmented.
But once I showed it to friends, the reaction changed the entire vibe.

They did not just say "cool demo."
They started asking for it.

That matters more than it sounds like it should.
Friends are often the first real signal that you have built something with actual utility.
They are not your target market in a rigorous statistical sense,
but they are usually honest about whether something feels useful.

The requests started small:

can I try it?
can you send me the link?
can it handle this kind of paper?
can it give me a cleaner output?

Then the requests got more specific.
They wanted a simpler way to use it.
They wanted a nicer interface.
They wanted the thing I had been using for myself to work for them too.

That is a powerful moment for any builder.
It means the project has escaped the original use case.
It is no longer just a private utility.
It has crossed into "other people can imagine themselves using this."

That feedback also exposed the real product shape.
The CLI was enough for me, but not enough for everybody.
If I wanted other people to use Archimedes without a tutorial and a prayer,
I needed to build a more approachable interface.

That is the exact moment the project started becoming a product.
Not because I declared it so.
Because other people started demanding it.

The First Version Was Just a CLI - and That Was the Point

Harshal Rudra — Tue, 14 Apr 2026 14:38:20 +0000

The First Version Was Just a CLI - and That Was the Point

The first working version of Archimedes was not a polished web app.
It was a CLI tool.

And honestly, that was the correct move.

When you are trying to prove a workflow, the CLI is brutally useful.
It strips away all the distractions.
There is no fancy UI pretending to solve the problem for you.
There is just input, output, and the question:
does this actually help?

My early CLI version focused on the core loop:

enter research keywords
ask a research question
fetch papers
run analysis
print a structured answer

That was enough to learn a lot.

I found out quickly that the magic was not in making the tool look impressive.
The magic was in whether the pipeline felt useful.
If the CLI could turn a messy research prompt into something structured and evidence-based,
then I had something worth keeping.

The CLI also forced discipline.
It made me think about the minimum useful workflow.
What is the smallest version of this idea that still feels like a real product?

That led to the current shape of Archimedes:

search arXiv and OpenAlex
deduplicate and normalize papers
analyze each paper with an LLM
aggregate findings
synthesize a direct answer
export the result as a PDF

A CLI is not sexy.
It is not marketable in the same way a shiny website is.
But it is perfect for proving that the thing actually works.

Once the CLI felt useful for me, I knew the next step was not "make it prettier".
The next step was "make it accessible."

That is where the web version came from.

Why Existing Research Tools Weren't Enough

Harshal Rudra — Mon, 13 Apr 2026 09:47:32 +0000

Why Existing Research Tools Weren't Enough

Before building Archimedes, I did the obvious thing: I looked around for tools that already solved the problem.
And to be fair, there are a lot of good ones out there.

I tried the usual suspects and explored tools that were good at pieces of the workflow:

paper search
literature discovery
summarization
note organization
citation management

The problem was not that these tools were bad.
The problem was that none of them matched the exact shape of the workflow I wanted.

I wanted something more end-to-end.
Something that could start from a research question, pull relevant papers from sources like arXiv and OpenAlex,
analyze them with an LLM, and then produce a direct answer with paper-level evidence.

A lot of tools stop at discovery.
Some stop at summaries.
Some stop at note-taking.
Some are good for collecting information, but not for turning it into a structured report.

That gap mattered to me.

I did not just want more information.
I wanted synthesis.
I wanted a result I could hand to myself or someone else without manually doing all the glue work.

That was the key realization:
the value was not in any single step.
The value was in chaining the steps together into a workflow that felt natural.

So Archimedes became a research assistant instead of just a search tool.
It searches, analyzes, aggregates evidence, and exports the final answer as a PDF.
That is the part I kept coming back to.

It was also the point where the project stopped being "maybe I should build this" and became
"apparently I need to build this because nothing else quite fits."

In the next post, I will talk about the first version that made that idea real:
a simple CLI tool that worked for me before it worked for anyone else.

How Archimedes Started: A Research Tool I Built for Myself

Harshal Rudra — Sun, 12 Apr 2026 08:05:28 +0000

How Archimedes Started: A Research Tool I Built for Myself

I did not start Archimedes because I wanted to launch a SaaS.
I started it because I was sick of doing the same research ritual over and over:
search a paper, open five tabs, skim abstracts, save PDFs, forget half the useful bits,
and then try to stitch everything together into something that actually answers the question.

That sucked.

Archimedes began as a very personal fix for that exact mess.
I wanted something that could help me search academic papers, analyze them with an LLM,
synthesize evidence, and spit out a clean answer I could actually use.

The first version was not elegant.
It was just me trying to make one painful workflow less painful.
But that is usually where the good stuff starts: not with a business plan,
but with a tiny recurring annoyance that refuses to shut up.

The core idea was simple:

search academic sources
identify the most relevant papers
analyze them with an LLM
collect evidence in a structured way
export the final result as a PDF

That is Archimedes in one sentence.

I built it because I wanted to stop doing research like a caffeinated raccoon,
opening random tabs and pretending I had a system.
I wanted one place where a question could become a useful answer.

The funny part is that the more I worked on it, the less it felt like a toy.
The pipeline started making sense.
The workflow became repeatable.
And once something becomes repeatable, it starts becoming a product.

This is the first post in the story of Archimedes.
The next ones are about the ugly middle bits: looking at existing solutions,
building a CLI, showing it to friends, and slowly realizing the thing had legs.