DEV Community: AlexGR

XP-R — Technotes: Slowing Down to Scale: Building Context as a Force Multiplier

AlexGR — Thu, 12 Mar 2026 22:16:30 +0000

This post complements the previous entry (XP-R — Slowing Down to Scale: Building Context as a Force Multiplier).

Decoupling Identity from the Game

I’ve separated the "Human" (Auth/Security) from the "Avatar" (In-game entity).

The Logic: identity handles the account; characters handles the persona.
The Payoff: A clean User model and a future-proof path for multi-character support without touching the auth core.

The Workspace Pattern (Multi-tenant)

Instead of building custom logic for Orgs, Alliances, or Communities, I’ve unified them under a Workspace model.

The Goal: Build features like DKP or Calendars once.
The Result: The system is agnostic; it doesn't care if you are a massive fleet or a small squad, the tools just work.

Namespacing & Fleet SSOT

I’m organizing features into public_features and private_features. It’s a clean split between global platform value and premium group tools.

Additionally, I’ve locked down the Fleet logic: Ships are managed in a Single Source of Truth. Other modules can link to ships, but they can't create them. Consistency is non-negotiable.

The xpr Modular Monolith

The backend is structured to keep domains isolated but reachable:

Core & Workspaces: The infrastructure and tenant logic.
Meetings: The dynamic engine for event lifecycles.
Realtime & Gateway: The entry points for the frontend (xsr).

Clean Connections

To avoid the classic Django circular import nightmare, I’ve mandated using the App Registry for cross-module relations. It keeps dependencies flat and the architecture predictable.

Next Step: With the architectural context now locked in, I’m moving into the final polish of the database models before the first "real" lines of code are written.

XP-R — Slowing Down to Scale: Building Context as a Force Multiplier

AlexGR — Thu, 12 Mar 2026 21:57:22 +0000

This week, I decided to further push back the urge to start "cranking out code"—a drive fueled by the desire to see something functional—to focus instead on the database and conceptual structure of my project.

While I haven't finalized the data modeling phase yet, the progress is solid. I have already projected the logic for:

Identity: Users, personas, and organizations.
Core: Meetings and subgroup systems.
Scalability: A design focused on future phases to prevent traumatic refactoring down the road.

The Weight of Spec-Driven and Context-Driven Dev

After several sessions with the Gemini 3.1 Pro planner, what I initially envisioned as a "quick start" has turned into several days of technical profiling. I’ve immersed myself in specification-driven development, detailing complex workflows and how they integrate with the system's core event logic.

To ensure the planner and future agents operate with precision, I have synthesized all the project knowledge into four pillars of technical context:

Structure and Namespaces: Defines the strict topography of the modular monolith. Any new model, service, or feature must fit into this anatomical tree.
Architectural Framework: The set of strict rules and technical standards governing all Starnet (ABX11) development.
Meetings and Dashboard Logic: Defines the lifecycle of "meetings" (a key piece of the MVP) and describes dashboard features, including those not slated for immediate implementation.
System Architecture: The conceptual and detailed business logic that gives meaning to the entire system.

Changing My Stance on Agents

My boundaries have evolved. Although I didn't originally plan to use agents, the ability to isolate them restrictively—thanks to a clean Django architecture and extreme context definition—has shifted my perspective.

In the best-case scenario, this will allow me to massively accelerate development. At the very least, I’ll have an impeccable documentation base to work with AI as a consulting partner that understands every rule of my architecture.

The Dilemma: Vertical Development vs. Visibility

I am considering moving forward via vertical tasks: API-First (models and serializers for DRF), followed by backend logic and a functional temporary UI.

I’m aware this means delaying the visibility of finished modules. Applying the same descriptive rigor to the frontend as I have for the backend takes time, even if it’s just for a testing tool. Nevertheless, I am quite optimistic about the starting point I’ve achieved.

I’ve included the denser technical details, and ADRs (Architecture Decision Records) in my TechNotes associated with this post to keep this narrative focused on strategy -> XP-R — Technotes: Slowing Down to Scale: Building Context as a Force Multiplier.

XP-R — Preparing the Foundations (Tech Notes)

AlexGR — Fri, 06 Mar 2026 12:33:39 +0000

This post complements the previous entry (XP-R — Preparing the Foundations), focusing on the technical implementation details behind XP-R’s architecture, module structure, and Identity module setup.

Technical Notes

Some additional implementation details that were established during this
phase:

Models and module organization

Models are placed inside a models/ package using pluralized files to group related classes.\
This allows multiple related models per file without breaking Django conventions.\
It also helps avoid circular dependencies while keeping the structure scalable.

Identity module configuration

default_auto_field = 'django.db.models.BigAutoField' is explicitly
configured to prevent issues with very large datasets in the future.

Nested Django apps

Because apps are inside the modules directory, a few Django-specific
adjustments are required.

INSTALLED_APPS explicitly imports the AppConfig:

modules.identity.apps.IdentityConfig

Using only modules.identity relies on Django's implicit discovery
mechanism, which can sometimes produce confusing behavior in more
complex structures.

General guidelines used in the project:

Python imports use the full path: modules.identity...
The name variable in apps.py also uses the full path: modules.identity
Database references and Django metadata use the short label: identity

Shared model utilities

A base abstract model called TimeStampedModel was introduced in the
Core module, providing:

created_at
updated_at

This keeps models consistent across the project while avoiding repeated
boilerplate.

API serialization strategy

The first serializer implemented was UserSerializer in the Identity
module.

The project follows two rules for API design:

incremental database IDs are never exposed
only UUID-based identifiers are used externally

Serializers are organized per module inside a serializers/ directory,
using pluralized filenames such as:

user_serializers.py

This prevents monolithic serializer files and helps keep the API layer
modular as the platform grows.

XP-R — Preparing the Foundations

AlexGR — Fri, 06 Mar 2026 12:29:43 +0000

The last few work sessions on XP-R were mostly about preparing the
project's internal structure before real feature development begins.

A significant amount of time went into thinking through the architecture
before even installing Django. The goal was to make sure the backend
structure would work not only for the web platform, but also for future
components like the overlay, realtime features, and external
integrations such as a Discord bot.

It may look slow from the outside, but investing time here helps avoid
structural problems later.

Documenting Decisions

I also decided to start documenting architectural decisions using
Obsidian.

The idea is not to maintain extremely detailed technical documentation,
but to keep track of:

architectural decisions (ADRs)\
design reasoning\
ideas and future considerations

Basically, enough context so that if I step away from the project for a
while --- or if someone joins later --- the structure and reasoning
behind the system are still clear.

AI Tools and Development Workflow

After some research, I finally installed Antigravity to experiment
with its planning capabilities, mainly using the planner with Gemini
3.1 Pro.

For now, I’ve decided not to adopt an agent-first workflow. Early stages of a project are usually the most fragile from an architectural perspective, and introducing autonomous agents too soon can easily create unnecessary complexity before the foundations are properly structured, though I might be mistaken.

The only exception is a security-focused agent that accompanies the development process, helping review potential vulnerabilities and risky patterns as the system evolves.

One interesting observation during these tests is that many AI tools
tend to apply generic OOP patterns to Django, ignoring how the
framework actually works internally. The Gemini 3.1 Pro (High)
responses were noticeably closer to real Django practices, which made it
more useful as a reference during architectural decisions.

Infrastructure Adjustments

I originally planned to start with Docker, but I'm working on a
cloud PC, and this environment doesn't allow virtualization, so that
idea was postponed for now.

Instead, the current stack looks like this:

PostgreSQL from the start (no SQLite phase)\
Redis in the cloud via Upstash (the same problem as with Docker)\
ASGI configured, with Django Channels ready

So even though the platform is still early, the backend is already
prepared for realtime features.

Project Structure

The Django project follows a modular monolith structure, grouping
apps inside a modules directory.

modules/
  identity/
    models/
    services/
    selectors/
    admin/

Each module encapsulates its own domain and separates data models,
business logic, and read logic.

The motivation behind this structure is simple:

High cohesion by domain\
Low coupling between modules\
Clear separation between models, logic, and read operations\
Preparation for organic growth of the modular monolith\
Possible future fragmentation into independent services\
Better mental clarity when thinking about the system at scale

This approach keeps the project maintainable as it grows, while still
leaving room for future architectural evolution if needed.

Identity Module

The first module implemented is Identity.

A custom user model was created before running any migrations,
including a UUID-based identifier that can be used consistently
across APIs, realtime channels, and potential future services.

To simplify realtime interactions, the user model also exposes a small
helper property used to standardize the user's realtime channel group:

@property
def realtime_group_name(self):
    return f"user_{self.user_id}"

This avoids rebuilding the group name in multiple places across the
codebase and keeps the realtime layer cleaner.

The API layer also follows a simple rule from the beginning:
incremental database IDs are never exposed --- only UUIDs.

Overlay Architecture Considerations

One architectural question that remains open relates to the overlay
application.

The web platform will likely continue using Angular, which works
well for complex dashboards and administrative interfaces. However,
overlays introduce very different constraints, especially when running
alongside a game like Star Citizen.

Angular's runtime behavior, including aspects of its garbage
collector, bundle and heavier runtime, could potentially introduce
performance risks in that environment.

Because of that, I'm evaluating whether the overlay might instead use
something lighter like Svelte, while Angular remains responsible for
the web platform and dashboards.

This would mean running two frontend frameworks, which obviously
adds complexity, so the decision isn't final yet.

The desktop layer itself will most likely rely on Tauri, which seems
well suited for building a lightweight overlay-style application.
However, a few key capabilities still need to be verified, such as:

transparent windows\
click-through behavior when needed\
capturing input when required

In the near future I plan to build small prototype overlays that
simulate realistic UI load and realtime updates in order to test
performance under stress.

Current State

At this point the project has its basic foundation in place:

PostgreSQL database configured\
Redis cloud integration\
ASGI and Channels prepared\
Modular project structure\
Identity module started

Not a lot of visible features yet, but the structural groundwork is
now ready, which should make the next development steps much smoother.

More Technical Notes

Some of the deeper technical details behind this setup are documented in a separate companion post -> XP-R — Preparing the Foundations (Tech Notes).

XP-R — Day 1: Core Alpha 1

AlexGR — Wed, 25 Feb 2026 16:47:01 +0000

Today was the first real day of work on XP-R.

The day started with some analysis and reflection: evaluating the project’s viability, identifying potential risks and challenges, and reconsidering what the platform can realistically achieve. It was a necessary step to clarify the scope and ensure the work ahead is focused and sustainable.

Once I had that context, I reactivated my presence here on dev.to, reacquainted myself with the workspace, and reconditioned ClickUp to manage tasks and workflow properly. Clear segmentation, no floating notes, a process that makes the day-to-day visible and trackable.

Preparing the Data Layer

The first practical step was modeling the initial database structure with dbdiagram. This structure covers the immediate needs of Core Alpha 1 while remaining compatible with features planned for later stages. It includes support for:

User creation and account linking
Character management
Organization membership flows
Multiple activity types per organization
Participation and lifecycle tracking
Configurable progression points (DKP-like mechanics)
Assignment of points after activity completion

Working through this with dbdiagram allowed me to iterate quickly and validate relationships without committing to premature implementation decisions.

Considering AI and Agents

I also spent some time evaluating tools for development: whether to start using Google Antigravity, Cursor with Claude Code, or continue with VSCode.

I’m aware of the value of agent-based AI systems and I’ve used them in other projects at more mature stages, but for this early phase I want to avoid possible overengineering or unnecessary complexity.

I will still use AI extensively for tasks like modeling, iteration, and validation, and its role will grow as the project evolves. For now, XP-R will not be “Agents First”, keeping the focus on clarity, speed, and building solid foundations.

A small but productive first day: clarifying the project’s boundaries, preparing the workspace, laying down the initial backend foundations, and deciding how AI will integrate without overcomplicating the early phase.

Welcome to XPanel Reforged (XP-R)

AlexGR — Wed, 25 Feb 2026 16:26:04 +0000

As I mentioned in my first post, I’m back on dev.to after a few years, and returning to a project I had to pause: XPanel. That post shared a bit of the context.

Since this is a clean restart, the project now has a new name:

XPanel Reforged

—or XP-R for short.

Same core idea. But approached with better clarity, execution, and sequencing.

What XP-R Is

XP-R is a platform for a multiplayer game communities — a central hub where organizations and players can coordinate, track progression, and experiment with social and gamified features. Think of the solutions communities often implement themselves through Discord, spreadsheets, WordPress sites, or other tools — XP-R aims to unify and simplify that in one place.

Even individual players will find value: the hub allows experimentation with these features without belonging to a structured community, providing a personal space to engage, track, and explore.

The platform will include gamification elements, activity tracking, and systems designed to support collaboration, progression, and recognition — but always in a way that serves actual user behavior, not just as arbitrary mechanics.

How This Version Differs

Over the years, my perspective has evolved. I have a clearer view of what the platform actually needs, how users behave — solo players, small groups, large organizations — and what should exist in the first functional version versus what can wait. XP-R isn’t exactly what I imagined years ago; it’s the product of experience, reflection, and iterative thinking.

This is why XPanel Reforged exists. Not a rewrite. A repositioning. Same core idea, but approached with clarity and better execution.

I’m thinking in terms of MVP-first, behavioral validation, and long-term maintainability. Features aren’t added because they’re cool — they’re added because they move the product forward in a meaningful way.

XP-R is the foundation for the journey ahead — a flexible, structured, and human-centered platform that can grow and adapt as both players and communities evolve.

XPanel Reforged – Starting Again, But Not From Scratch

AlexGR — Wed, 25 Feb 2026 15:51:26 +0000

Hey dev.to 👋
It’s been a few years.

I’ve been around, building, experimenting, shipping things… but I haven’t written here in a long time. And honestly, I’ve missed it.

So today I’m coming back with something that feels both familiar and completely new.

The Project That Never Fully Left

A while ago I started building XPanel — a social platform designed around a multiplayer game community. It was ambitious: organizations, progression systems, structured activities, reputation, internal coordination… all the things communities try to manage with spreadsheets, Discord threads and a bit of chaos.

The stack back then included:

Django
Django REST Framework
Docker
Angular
Redis
and a handful of other supporting services

At the time, I was still getting comfortable with several of those technologies. The architecture worked, but it wasn’t solid. Continuing from that codebase today would mean complex migrations, structural refactors, technical debt carried forward and compromises I’d rather not accept.

On top of that, my understanding of player dynamics — solo players, small groups, large organizations — was still limited. I was building features based on assumptions.

Fast forward to today:

I have significantly more experience with the stack.
I understand community behavior much better.
The game ecosystem itself has evolved — some features I once considered critical are no longer necessary, while others have become far more valuable.
My vision of what actually needs to be built is much sharper.
And, of course, we now live in the era of AI-assisted development, which dramatically changes execution speed and iteration cycles.

So instead of patching the past…

I’m restarting.

So, welcome back. Let’s build this properly. 😊

XPanel #8: Activities 5/*

AlexGR — Sat, 30 Oct 2021 15:55:05 +0000

PostHolder

XPanel #7: Activities 4/*

AlexGR — Sat, 30 Oct 2021 15:54:24 +0000

PostHolder

XPanel #6: Activities 3/*

AlexGR — Sat, 30 Oct 2021 15:49:46 +0000

Wrong English Disclaimer

Ok... this is a PostHolder xDDDD

Maybe I will write with detail all the steps I done this days in the future, but it were hard and it were looot of them.. and I had to handle a lot of things related with the proyect and non related (my life things)..

Simplify..

Full finish the template system.
Thinking about all possible templates for phase 1 activities and all the requirements (roles and assets) and add all of this to the plataform by the admin system.
I was more than 2 days working in the match making algorithm, this should be a only one post talking about it
Finishing the whole activities module, this is a good point, the most important and hard part was done :)
I was other 2 days learning about docker and implementing it to my project.
Migrating from sqlite3 to postgres, adding celeris, flower, redis, learning about Django REST Framework and how to I should implement,..
How to implement a OAuth Token to auth the api client and the different methods.
Solving problems with a looooooot of star citizen relevant persons and fixing possible problems what I think I probably have in the growth time of the plataform, again I should write one single post talking about this, was a lot of time and relevant choices.
Trying choose a frontend framework and a css framework... after a loot of time I choosed Angular and probably Material Design.

Anyway.. I should wrote all this process, doesnt care if I was really bussy this days.. my bad.

Whatever.. I'm going to start learning Angular right now,.. wish me luck :)

XPanel #5: Activities 2/*

AlexGR — Thu, 21 Oct 2021 08:05:10 +0000

Wrong English Disclaimer

ajdpfojaspdfojajpadf

I should finish my last post before..

I'm going to resume a lot all what I was doing..

I need more players advising me about ingame details, at least while I'm with activities module... this is important.. so I decided start one of my old ideas: The Star Council

This have to be a group of compromissed players who will decide the ingame details of the plataform features.. to evite me take choices by myself, or other single person by hisself..

So..

I told some players about that and it was hard to xplain without visual support... lets create a logo and a picture to try explain correctly the concept:

(Wrote in spanish cause I was going to show it only to spanish people in first moment)

Ok, with the visual support I ask other relevant players or organizations leads to try start form this Star Council group, I really need help for the activity templates choices.. ..but.. no good resoults.. I'm having more help when I stream in Software Dev Twitch category than from Star Citizen players... they are friendly and love my idea but preffer still play than help :)

However two players was interested and they will try help me when they can,.. is not bad..

I start create the Google Docs table to visual show the game activities in phase 1 and wich I need detailed info from players to implement in the backend logic..

This activities grid was BAD, in the first moment I thought for example:

This changed the day before I created cause I understand its complicated implement acitivies who need different roles of different areas and where players has to PAY to other players for their services, and ofc they will need a "renounce explorer" and "renounce escourt" ... so much complicated for the users in the first phase of the plataform, and 20 activities was a lot.. so..

I set only the simply and main activities without complement with players of other areas... and I decided in the phase 1.X implement the Contrats section where players could offer their services, and then I can prepare it for groups or organizations too... this could be a big independent feature in the future.. and so much simple for first phase of plataform.

Ok, the problem continue, we had the activities of the game areas choosen, leeeeeeeets go prepare the templates... I continue the Google Docs with the detailed data and try start form it with one player help, but .. until the day im writing this post (2 days later) we had only mining activities details.. -.-'

After some changes and some different setups the table was like that:

As you can see, like I explained in my last post, there are different Game Areas > Every Game Area has different Activities (What player choose to play) > Every Activity has different templates (What backend use to try start activity) > Every template has his requiriments, and his required assets as group, and his related roles, wich they had his required assets too.

So the point in backend logic will be every time one player start queue is ask him the assets related to the activities he choosed and check how many roles can he play with this assets, after that, check if there are any template full of roles looking from the first player in queue and if we have available temlpate, then check if the players in it has enought assets to really start the template.

Everything of this checking language filter, time to play and taking players together if they queue up in group, this features are not implemented yet.

I'm resuming a looooooot all the process cause I had to include in DB the required_assets tables, solve the initial problem and think how to ask the assets to users with the simply form to still run like "Click and Go" concept what I want in plataform..

Obviously I create some html with activities list, temporally check buttons to chose it and a simply text inputs to all assets to test the functions, after a lot of work it was working..

I had to implement a system to send to front the (ActivityID + Asset + Minimum + Maximum) for every asset in every active activity to let a future JS script verify the choices and ask about only the needed assets to user before sent form.
I implement the logic to check if with this assets the user has viable roles in backend and create the activity queue record and save all the posible roles and his assets list (it was not implemented in models yet)
To make this viable I had to implement a first concept of characters list in characters app to let user select his active char between the chars he has claimed..

It was bad implemented, cause I wanted include the whole active_character object in sessions like user,.. and I didnt find the correct way cause it only let me JSON friendly add.. maybe I should save every data in different request.sessions[X] var, but I really didnt want it, and save one request.sessions[active_character_id] and call it in every view to then get it from DB is useless af.. I decided just implement my function to get active character and call it from the begin of eeeeeeeeeeevery view...

..this is BAD, I know, the correct solution probably was using a Middleware ??¿¿

Idk but I have not enought time to networking + designs + thinks in logic + thinks in gameplay details + learn python/django big and little things + dev the backend.... so, this works for now,..

sigh...

I didnt wrote it in correct time point, but I was like one day fighting vs the manytomany relations in django admin autogenerated forms, a few hours until I discover the StackedInline, and mooore or less I get a correct way to create templates without turn me crazy :)

Obviously I did a lot of more things, like 5 hours talking with different players getting super good feedback but zero help, etc..

I hope today I finish the activity module.. we will see..

Sorry for my awesome bad english and write style if you arrived here xD

Cya!

XPanel #4: Activities 1/*

AlexGR — Sun, 17 Oct 2021 08:13:29 +0000

Wrong English Disclaimer

Well..

Lets finish this fast xD

In this last two days I did..

Implement the models related with the automated activities system

I did something wrong the first day but fixed it the second, so I will show the result of the two days work xD

The first point was understand:

The game has multiple areas, for example mining, delivery, piracy, medical, etc.. so I temporally set a refered list in code, important think this is not xpanel activities list. I added a color list too.

Every "Game Area" in the game can have multiple "main activities", this is the different activities to choose in XPanel, and this main activities will be group by their game area.

** There are multiple "ActivityTemplates" for every "Main Activity", to let start the activity with different setups of players.

(To make this correctly work there are other aspects too)

So..

I implemented the models refered to the automated activities creation.
The models related to the automated activities queue system.
The model related to the data containers in different languages
I created new app named JIRE (Epic name) with the objetive of serve global information (Fixed in code or in DB) to all the others apps and operate with it if needed.
I implemented the admin forms of the info containers in different languages.
Learn how to include other models related fields correctly.

STOP!

There was something that will not work!

I went to contrast my ideas about the activities with other players in other discords and I was a few hours talking about possibles activities and the requiriments I will have to save in the db,... it was a real problem... I will have to include assets_list for every character??? This is expensive work for every user... and.. Have I got to include assets requiriments system for every template? This is work for me, but easy for users... I have to think more about it..

I spend a lot of time after my conversations thinking how to optimize the new requiriments in db about the requiriments for every role in templates and for the whole template..

Meanwhile all of this I tolk with one relevant streamer and he did a global poll about the most wanted roles in their viewers..

Ok, the most complicated game area to think activities for... its the most voted: Trading :) (I love this area too by the way)

I contact with two more content creators to talk about the progress of this activities system.

This post was really long and really bad wrote... CBA, I continue later, lets go dev!