From Idea to arXiv: My Workflow for Building and Publishing AI Research as an Independent Researcher

Breaking into the world of academic research can feel impossible without being part of a major university or a corporate lab. But I believe that with today’s tools, anyone with a good idea and a lot of persistence can contribute. This is the story of the workflow I’ve developed to go from a simple concept to a fully functional AI application, and finally, to a publishable research paper.

It’s a journey of building, debugging, and thinking strategically not just about the code, but about the research itself. Here is my four-step process.

Step 1: Start with a High-Impact Tool, Not a Vague Idea

Many academic projects start with a vague research question. My approach is the opposite: I start by building a tool that has an immediate “wow” factor and solves a tangible problem. The goal is to create something that a person can use and understand in seconds.

For example, my first project, the AI Marketing Strategist, was built on a simple premise: give it two company websites, and it generates a comparative strategic analysis. It’s immediately useful and demonstrates the power of the underlying technology.

This “tool-first” approach ensures that the project is grounded in a real-world application, making the subsequent research far more relevant.

Step 2: Build Fast and Free with a Serverless Stack

As an independent researcher, I don’t have access to massive budgets or university server clusters. My entire workflow is built on a modern, serverless stack with generous free tiers, allowing me to build and deploy globally-scaled applications at virtually no cost.

This stack allows me to go from an idea to a deployed application in a matter of days, not months. The “wilder” the idea, the better, like my AI Debate Chamber, which uses this same stack to simulate a full debate between two AI personas and have a third AI judge the outcome.

Step 3: The Crucial Pivot – Turn the Tool into an Experiment

This is the most important step in my workflow. A tool is a cool demo. But a tool that is designed to **collect data** is a scientific instrument. This pivot is what transforms a personal project into a piece of research.

My latest project, the Prompt Engineering Benchmark, perfectly illustrates this.

Suddenly, the application is no longer just a demo. It’s a data collection machine for a formal experiment designed to answer a real research question: “Which prompting method is best for this task?”

Step 4: Write the Paper About the Data, Not the Tool

With the data collected from the experiment, the final step is to write the research paper. The key here is that the paper’s primary contribution is not “I built a cool app.” The contribution is the **new knowledge generated from the data collected by the app.**

My paper, “An Empirical Evaluation of Prompting Strategies,” presents a table of the average scores for each prompting method. The conclusion isn’t about the app itself, but about the data-driven finding: that for this task, Few-Shot prompting is dramatically more effective than the other methods. This is a concrete, evidence-based contribution to the field.

The Struggle is Real (And Part of the Process)

This workflow isn’t always smooth. I’ve spent countless hours debugging Vercel deployment logs, fixing subtle configuration errors in package.json and tailwind.config.ts, and dealing with the frustration of having my first papers put on hold by arXiv moderators. But this iterative process of building, failing, learning, and refining is what leads to a final, robust result. Each error is a lesson, and each setback is a chance to improve the strategy.

My Portfolio of Work

This entire process—from idea to tool to experiment to paper—is a repeatable loop. You can see it in action across all my projects.

I believe that by sharing our tools, our data, and our stories, we can create a more open and accessible future for research. I encourage you to explore my work, build on it, and start your own journey from idea to publication.