I've spent a fairly unreasonable amount of time playing space games. Mostly Star Citizen and Elite Dangerous, two games that have given me hundreds of hours of entertainment and an equally impressive number of opportunities to stare at spreadsheets.
If you've played either, you'll know that the games themselves are only part of the experience. Eventually you're looking up ship specifications, comparing components, planning trade routes, calculating jump ranges or trying to remember which station sells something you need.
There are already some excellent community tools for both games, but I've often found myself jumping between websites, each with its own interface, data sources and way of presenting information. I wanted something that brought more of those tools together, with a consistent design and information that was easier to navigate.
That became SPACE // STUFF, a collection of tools for Star Citizen and Elite Dangerous. What started as a small personal project has grown into ship databases, loadout builders, trade tools, crafting calculators, resource finders and a fairly substantial amount of technical work I hadn't originally planned on doing.
It's been an interesting exercise in design, programming and figuring out how much complexity you can introduce into a website before it becomes as difficult to use as the games it's supposed to help with.
Designing for People Who Actually Use the Tools
My background is in marketing, design and content, so naturally I spent a considerable amount of time thinking about how the site should look. I wanted something that felt like a technical interface without becoming visually exhausting. Dark backgrounds, restrained typography, compact information panels, subtle borders and a limited colour palette became the foundation.
The identity uses the SPACE // STUFF name, with the double slash becoming a recurring visual element. Green is the primary accent, with brighter colours reserved for information that benefits from them, like prices, status changes and trends.
One of the biggest lessons was that clean design doesn't always mean more whitespace. When you're designing a portfolio or marketing website, giving everything room to breathe is usually a good idea. But when someone is comparing twenty ship statistics, spacing everything out can make the interface considerably worse.
Elite Dangerous ship outfitting is a good example. The classic style of tools like Coriolis puts an enormous amount of information on screen. It isn't particularly modern-looking, but there's a reason experienced players appreciate it. Rather than replacing that approach with larger cards and more generous spacing, I wanted to retain the information density while improving the typography, hierarchy and visual consistency.
The same thinking applies to responsive design. A complex ship builder can't simply be squeezed onto a phone screen. Some information needs to be reorganized into tabs or grouped differently, while the underlying calculations remain the same.
The challenge has been finding a balance between making the site visually interesting and keeping it genuinely useful. If someone is comparing two shield generators, they probably don't need an elaborate animation introducing the comparison table.
Building the Tools
The ship databases were an obvious starting point. Both games have enormous amounts of information associated with their ships, and much of it becomes more useful when you can compare it directly.
The Star Citizen side includes a searchable ship and vehicle catalogue, component information, comparisons, a ship builder and a personal hangar. Elite Dangerous takes this further into outfitting and engineering, where modules, mass, power requirements, shields, armour and modifications all affect performance.
This is where the project became more technically complicated.
Displaying a ship's specifications is relatively straightforward. Calculating how those specifications change when someone swaps a module or applies engineering modifications is another matter entirely.
Changing a component might affect a ship's total mass, which influences jump range and other performance characteristics. Shield calculations depend on several variables, including the relationship between the generator and the ship's hull mass. Engineering introduces additional modifiers that need to be applied correctly.
Crafting creates similar challenges. Different blueprints require different quantities, materials can have different units, and some recipes include alternative inputs or quality requirements. The crafting planner needs to calculate those relationships, combine materials across multiple items and produce a useful shopping list.
I've also been connecting related tools. If a crafting blueprint requires a particular material, it makes sense to link directly to that material in the Resource Finder rather than making someone search for it again.
The goal is to make the tools work together in ways that reflect how people actually play.
The Technical Side: Data Is the Real Project
One thing became obvious fairly quickly: building the interface is only part of the work. The bigger challenge is data.
Neither Star Citizen nor Elite Dangerous provides one convenient source containing everything needed for a site like this. Different tools require different services, each with its own structure, update schedule and limitations.
For Elite Dangerous, the site uses community services such as EDSM and Spansh, alongside other datasets for particular information. Star Citizen has its own community-maintained APIs and databases covering ships, components, crafting and other game systems.
These sources don't always describe things in the same way. One might identify a location by a particular ID, another by its name. Some provide numerical values, while others use categories or different units. Information may be updated frequently or remain unchanged for months.
The website needs to retrieve that information, normalize it into a consistent structure, check for missing or invalid values and apply calculations where necessary.
That sounds straightforward until a service changes its response format, a game patch introduces new equipment or a particular record turns out to be incomplete.
Accuracy is particularly important for tools like trade route planners. A route might look incredibly profitable based on reported prices, but supply and demand can change before someone arrives. Displaying the age of information and warning about uncertain availability is just as important as calculating potential profit.
The same principle applies to ship and crafting calculators. It's relatively easy to make a slider update a number on screen. Making sure that number reflects the actual game mechanics is considerably harder.
Some mechanics are well documented. Others are partially understood or change between patches. When reliable information isn't available, I'd rather acknowledge the limitation than display a convincing calculation that's completely wrong.
Showing a number isn't the same as proving it's correct.
Where AI Fits Into the Development Process
One of the more interesting parts of building SPACE // STUFF has been figuring out where AI actually makes sense in my workflow.
I've written before about my mixed feelings toward AI-generated creative work. I'm not particularly interested in handing over the design of something and accepting whatever comes back. I enjoy making those decisions, and I think they're a big part of what gives a project its personality.
For this project, I've taken a different approach. The design, visual identity, layout decisions and overall look and feel are my work. AI helps with the technical side, particularly mathematics, calculations, coding and data integrations.
Both games involve complicated systems, and translating those systems into working tools requires research, logic and testing. AI has been useful for working through formulas, understanding relationships between variables, troubleshooting code and connecting different data sources.
It's also helpful when an API returns information in an unexpected format or a calculation isn't producing the result it should.
That doesn't mean the answers are automatically correct. AI can produce a convincing formula that's completely wrong, especially when the underlying game mechanics aren't fully documented. The results still need to be checked against reliable information and tested with real examples.
On the creative side, I wanted the site to reflect my own preferences. The colours, typography, spacing, navigation and information hierarchy are intentional decisions. I've spent plenty of time adjusting individual elements because something didn't feel right, even when it was technically functioning perfectly.
I think there's an important distinction between using AI to help build something you've designed and asking AI to decide what you should build. The former can remove technical barriers and make ambitious personal projects more achievable. The latter risks producing something that works but doesn't have much personality.
For me, this has been one of the more useful applications of AI I've encountered. I don't need to personally solve every mathematical problem or write every integration from scratch, but I still need to understand what the tools are doing, recognize when something isn't working and make the final decisions.
And frankly, I'd much rather spend an afternoon refining the interface than debugging a formula that calculates shield strength incorrectly.
Building for Games That Keep Changing
Another complication is that neither game stands still.
Star Citizen is still in active development. Ships change, components change, new mechanics arrive and information that was correct for one patch may be wrong in the next. Elite Dangerous is more established, but it also continues to receive updates and new content.
That makes maintaining accurate information an ongoing challenge. Wherever possible, data needs to be refreshed from maintained sources rather than manually entered into hundreds of pages.
It also means building interfaces that can handle missing information gracefully. If a ship has no verified purchase price, the site should say so. If a calculation isn't supported by reliable data, it shouldn't quietly invent one.
There's also the less glamorous side of maintaining an interactive website: tooltips that refuse to disappear, tables that become difficult to read at smaller sizes, filters that behave unexpectedly or calculations that fail to update when someone changes an input.
Those details aren't particularly exciting to talk about, but they're often what separates a useful application from a frustrating one.
A Different Kind of Creative Project
What's been particularly interesting is how much the project overlaps with the work I already do in design and marketing. There's branding, visual identity, information architecture, UX, content organization and a surprising amount of problem-solving around how people interpret information.
But there's also a different kind of satisfaction in building something functional.
A marketing website usually has a fairly clear objective: explain the offering, communicate the brand and encourage someone to take an action. A tool needs to help someone accomplish a task, and that changes how you evaluate the design.
It doesn't matter how nice a calculator looks if the result is wrong. A beautiful ship comparison page isn't useful if you can't find the statistic you're looking for. A trade tool with an impressive interface isn't doing its job if it hides the age of its data.
The quality of the experience comes from how well the design and functionality work together.
I've found that genuinely rewarding, particularly because the project combines two things I enjoy: making things and playing space games.
There's Still Plenty to Do
SPACE // STUFF is very much an ongoing project. There are calculations to refine, data sources to improve, interfaces to simplify and additional connections between tools that could make the whole thing more useful.
I'm also aware that some of the best improvements will probably be relatively small. Better filters, clearer information, fewer clicks or a more intuitive way to organize a particular workflow.
Not everything needs to be a major new feature.
The project has been a useful reminder that you don't necessarily need to be an expert in every discipline to build something ambitious. You do need a clear idea of what you're trying to make, enough understanding to recognize when something isn't working and the patience to keep improving it.
AI has helped bridge some of the technical gaps, but the design and direction are the parts I enjoy most. Having tools that make the technical work more approachable has allowed me to take the project considerably further than I originally intended.
I didn't start SPACE // STUFF because I thought the internet desperately needed another gaming website. I started it because I wanted a particular combination of tools and information that I wasn't finding in one place, and because building things is fun.
If you're interested in Star Citizen, Elite Dangerous or simply seeing how the project develops, you can explore it at space.bvlderdvsh.com.
It started as a way to spend less time looking things up while playing space games. I'm not entirely sure it's saved me any time yet, but I've enjoyed building it.
