In this article
I’ve played EVE Online since 2009, which means I’ve spent a long time around its markets, trade hubs, hauling routes, player habits, and slightly strange economic rituals.
EVE has a reputation for being “spreadsheets in space”, and while that line gets dragged out more often than it probably deserves, there’s a reason people keep saying it. Under the spaceships and explosions, there’s a large player-driven economy where trading, hauling, manufacturing, speculation, logistics, and market timing all matter.
That market side of the game is what led to EVE Profit Routes.
The basic idea is simple enough: a player buys an item in one trade hub, moves it somewhere else, and sells it for more than they paid.
In practice, there’s a lot more to think about. The route might be too long. The item might not sell quickly. The market data might be stale. The cargo size might not fit. The profit might look good until you factor in the practical work of actually running it.
The question I wanted the app to answer was not:
What does the EVE market look like?
There are already tools that show market data, and some of them are very good.
The question I wanted to build around was more direct:
What should I haul right now to make ISK?
That became the starting point for the app.
What terralog.online is
EVE Profit Routes currently lives on terralog.online, which is my temporary home for small web app experiments.
I ended up with the domain after entering a coding competition on dev.to, so I’m treating it as a useful testing ground rather than the final home for every project I build. If one of the tools gets real traction, I can always move it to a better dedicated domain later.
For now, terralog.online is useful because it gives me somewhere to build in public, test ideas, and document the process without overplanning the whole thing to death.
EVE Profit Routes is the first serious app I’m building there, and it fits the Old Stack Journal angle nicely: a practical web tool, built with a simple stack, based on a real problem I understand from using the thing myself.
That last part matters because this isn’t an app idea pulled from a list of “micro SaaS ideas” by someone who has never touched the problem.
I know EVE well enough to know that market trading can be interesting, profitable, annoying, and oddly satisfying all at once. I also know how easy it is for an EVE tool to become a giant pile of tables that looks impressive but still leaves the player asking:
Okay, so what should I actually do next?
That is the question I wanted to keep coming back to.
The EVE market problem
EVE’s economy creates opportunities because prices vary between trade hubs.
A market trader or hauler might find that an item is cheaper in one location and more expensive somewhere else. That price difference is the obvious opportunity, but a good trade route depends on more than the gap between buy and sell prices.
In practice, a player needs to think about estimated profit, cargo volume, number of units they can move, route distance, market depth, freshness of the data, confidence in the prices, available wallet, existing assets, and whether the item is likely to sell at the destination.
Some of those details are pure numbers. Some are judgement calls.
A route with high theoretical profit can still be a bad choice if the volume is thin or the data is old. A route with lower profit might be better if it is shorter, cleaner, fresher, and easier to execute.
That is why I didn’t want EVE Profit Routes to start as a general market dashboard.
A dashboard can be useful if the player already knows what they are looking for, but it can also push the hard work back onto the user. It says:
Here is everything.
The kind of tool I wanted to build should say something closer to:
Start by looking at this.
The product loop I had in mind was:
Open → See the best run → Execute → Profit → Repeat
That loop is still the simplest explanation of the app.
It does not mean the tool should hide all detail or pretend the recommendation is perfect. This is EVE. Perfect is not really on the menu.
It means the interface, ranking, and supporting information should all point toward a practical next action.
Decision-first, not dashboard-first
The first product rule for EVE Profit Routes was:
Decision-first, not dashboard-first.
That rule sounds a bit like product-speak until you start making actual feature choices, and then it becomes very useful.
For example, if I add a sortable table, it should help the player compare route opportunities more clearly. If I add an item scanner, it should help someone investigate whether a specific item is worth trading. If I add a “Run This” action later, it should reduce the gap between seeing an opportunity and actually acting on it.
A feature does not belong just because it can be built.
This is especially important with EVE because the game has so much data available. Once you start pulling in market information, it’s very tempting to keep adding more views, filters, columns, and explanations.
Some of that will be useful.
Some of it will just make the app heavier.
The constraint I wanted to keep coming back to was:
Does this help the player decide what to haul next?
That question gives the app a shape.
It also gives me a way to say no to things, which is very handy when building alone and using AI to help with code. AI can generate a lot of features quickly. It can happily produce more screens, more filters, more helper classes, more clever little bits of nonsense.
What it can’t do on its own is decide which features belong in the product.
That part still needs a human who understands the user, the game, and the kind of tool being built.
Annoying, really. We still have to think.
Who this could help
The first audience for EVE Profit Routes is EVE players who already care about hauling or market trading.
That could be a newer trader who wants a clearer starting point, a returning player who understands the game but doesn’t want to manually inspect markets for an hour, or an experienced hauler who wants a faster way to spot runs worth checking.
The app could also help players with limited cargo space or limited wallet size, because those constraints change what counts as a useful route.
A profitable trade that only works for a freighter pilot with a large wallet is not the same as a smaller run that a newer character can actually execute. Later in the build, this becomes important when wallet-aware routing starts to behave too aggressively and needs rethinking, but even at the start the goal was to make routes feel practical rather than theoretical.
I also wanted the tool to help with decision fatigue.
EVE is full of “maybe” decisions.
Maybe this margin is good. Maybe the volume is enough. Maybe the item will move. Maybe the route is worth the jumps. Maybe someone is waiting to ruin your day because that is apparently their chosen art form.
A useful tool does not need to remove every judgement call, but it should reduce the amount of staring at data before the player can do something.
Why I started with a simple stack
The first version uses Apache, PHP, MySQL, HTML, CSS, and JavaScript.
I chose that stack because it fits the size and shape of the project. The app is mostly server-rendered pages, database queries, forms, route lists, tables, and small bits of JavaScript where the interface needs to respond without making the whole thing more complicated.
I’m not against frameworks, containers, build systems, or modern deployment platforms. They all have their place.
For this project, though, I wanted the fewest moving parts I could reasonably get away with. I wanted to know where the files were, how the routes worked, what the database was doing, and how to fix something when it broke.
The early structure looked roughly like this:
/var/www/eve
app/
config/
database/
public/
scripts/
storage/Apache serves the public/ directory, while the application code, config, database files, scripts, and storage sit outside the public web root.
That setup is not complicated, but it gives the app enough structure to grow without turning into one large file. It also keeps private and internal files away from direct web access, which is the kind of thing that is easier to get right at the start than retrofit later.
I’ll cover the server setup in a separate guide, but the short version is that this runs on a simple LAMP-style setup.
I’ve also got a guide for setting up a fresh Ubuntu home server for local web development:
How to Set Up a Fresh Ubuntu Home Server for Local Web Development
Getting the first version into shape
Week 1 was mostly about getting the foundation in place.
The early commit history shows the initial application structure and bootstrap scripts, followed by Git ignore rules and the removal of .env from the repository.
That’s not the most exciting part of building an app, but it is the kind of setup work that saves pain later. Once a project touches credentials, database settings, or API keys, private files need to stay out of Git.
The first structure included the expected pieces for a small PHP app: an entry point, a router, database connection handling, configuration loading, a home controller, an early route opportunity model, database schema, and setup scripts.
A small part of the bootstrap looked like this:
$db = Database::connection($config['db']);
$router = new Router();
$controller = new HomeController($db, $config);There’s nothing clever in that snippet, which is the point.
It shows the app starting with a clear entry point and enough separation that controllers, database work, and routing do not all collapse into one file. For a small tool, that is enough structure to move quickly while still being able to find things later.
Boring structure. Useful structure.
That’s a trade I’m happy with.
The first useful constraint
The most useful thing from Week 1 was not a specific file.
It was the constraint that the app should keep pointing back to the next hauling decision.
That constraint affects everything.
A market table is useful if it helps compare real opportunities. A route score is useful if it reflects practical trade-offs. A page explaining the app is useful if it helps a player trust the recommendation. Even the stack choice fits into the same idea: I wanted the technical setup to stay understandable so I could spend more time shaping the tool and less time managing the machinery around it.
This is also where my personal design and build angle comes in.
A small web app does not need to look like a venture-backed SaaS product to be useful. It needs to answer a real question, load reliably, explain itself clearly, and make the next action easier.
For EVE Profit Routes, that question is still the same one I started with:
What should I haul right now to make ISK?
Everything else should support that.
What I learned in Week 1
The main lesson from Week 1 was that a useful app needs a clear question before it needs more features.
EVE has enough data to send this project in a hundred directions, and a lot of those directions would be interesting.
Interesting is not the same as useful, though. That is the annoying little truth hiding under a lot of side projects.
The useful version of this app is the one that turns market data into a practical recommendation.
That does not mean the app should hide its reasoning, because trust signals matter in market tools. It does mean the data should support the decision instead of becoming the whole product.
By the end of this first stage, the app had a basic structure, a simple stack, early route generation, and a clear direction.
That was enough to move into the next problem: ranking.
Once the app can generate route opportunities, it needs to decide which ones are worth showing first. Raw profit isn’t enough, because a route can look good on paper and still be weak in practice.
Week 2 is where the build starts moving from:
We have route data.
to: Which routes are actually worth attention?