DEV Community: Jackfiallos

Building Solo: Architecture, Decisions, and Challenges After Launching Deeditt

Jackfiallos — Fri, 23 May 2025 15:05:30 +0000

A solid infrastructure doesn't guarantee users. Neither does a good idea, but sharing the journey?
That changes things.

👋 Who I Am and What I'm Building

I'm a software developer with years of experience building products from scratch, scaling infrastructure, and leading teams, but for the past few years, I've been working on something personal that I have named Deeditt.

Deeditt is a different kind of social network. While platforms like LinkedIn only celebrate achievements, Medium rewards articles written for algorithms rather than people, and the others where you can post anything you want, Deeditt offers something more authentic: documenting the journey whether personal or professional. What you learned, what you did wrong, what you had to rebuild from scratch.

It's a platform where you can share your real experiences through "deeds" (individual posts) and organize them into "journeys" (collections that tell a complete story over time). Think of it as a way to show "how I got here" not just "look where I am."

Have you ever wanted to share the stumbles in a project but couldn't find where that story fits? you're right, this is what Deeditt was built for.

🤔 Why I decided to build such thing

During job interviews and team building, I noticed how people often told small lies about their experience because there was no tangible way to prove otherwise. I kept thinking, "If there was a platform where people documented their actual journey, this wouldn't happen".

Like many who work behind complex systems, I felt something was missing: a space where people could share the process, not just the outcome. I wanted to read more about difficult decisions and less about brilliant successes, to have a better idea of people's real experiences.

So I decided to build it myself, because it's definitely better to learn from someone else's experience than from their final achievement where they usually say "I learned to roller skate, here are 5 tips that will teach you to go faster."

It took me about a year to mentally prepare for this long-term commitment, another year to develop the backend, frontend, server setup, and basic security, and yet another year to start testing the idea with real users. This timeline stretched out because I had a full-time job and Deeditt was my side project, which meant evenings and weekends were my development time.

📱 A wrong beginning? I Started with a Mobile App

When I imagined Deeditt, I saw it as a social network and automatically thought of a mobile app. It seemed logical, so I started building with React Native, a technology I already knew well and that allowed me to maintain a single codebase for iOS and Android.

So I started building the mobile app using React Native with TypeScript, along with Zustand for state management and React Navigation for routing. I chose this stack because it offered the best balance between development speed and performance. Some might argue that using Expo would have been a better choice, but at the time I started the project, Expo didn’t meet my needs. I required more flexibility and control than Expo could offer back then.

I started with just a few screens, but within months it grew so much that I kept introducing more and more features that I thought were "needed." This was the first trap - feature creep without users to validate what was actually necessary but on the other hand, I always was building this for myself.

But wait! Deeditt is also a free space for writing, for expanding ideas, for reflection, and that's not so comfortable on a small screen. Over time like a year after, I realized that starting with web might have been more effective for initial adoption. Visibility and long-form content fit better there. It wasn't a critical mistake, but an important lesson about how the platform defines product dynamics.

🌐 Building the Web Version: A Work in Progress

This realization led me to start working on a complete web version, which is what I'm doing now. Even though it's partially completed, there's a lot of work to do to fully match what I built in the mobile app.

For the web version, I'm using Astro Framework with Preact islands for interactive components - a perfect match for a content-first platform that needs good SEO and performance. I've decided to work in small stages and introduce features one by one. The first stage was deed details and journey detail pages, and now I'm working on authentication, deed posting, and more navigation pages for deeds discovery.

Though the mobile experience is excellent, I discovered many people prefer not to install new apps, especially in markets with geographic restrictions where the web offers greater accessibility. Fortunately, my architecture allows me to extend easily without having to rebuild everything from scratch.

🧱 Architecture: When the Stack Works But Isn't Enough

Technically, I set out to build a system that could sustain itself without constant intervention. So I developed a self-sufficient architecture, focused on efficiency and low cost. Basically, much of what cloud service providers do for you, I decided to do myself. The result is many hours of work, but an extremely low monthly expense to maintain the infrastructure.

I work with:

Docker for containerization, with services defined for production
GitHub Actions for CI/CD pipelines
Ansible with custom scripts that manage remote deployments on my VPS
Prometheus with Grafana for monitoring and visualization
New Relic for performance monitoring
Loki for log aggregation
Slack for real-time alerts
Rollbar for exception tracking
A set of microservices divided by functionality, each with its isolated PostgreSQL database that is using PgBouncer.

Most services are written in Node.js (NestJS framework), Python (FastAPI), and Go (Fiber), depending on the type of workload. API-heavy services are built with NestJS for its structure, computation-intensive services use Go for its performance, and data processing pipelines use Python for its rich ecosystem of libraries.

I don't use tools like Terraform or EKS. I want to maintain control and avoid unnecessary costs. My infrastructure-as-code consists of Ansible playbooks and shell scripts, which together handle everything from server provisioning to automatic SSL certificate management with certbot. Automation allows me to make monthly releases that rarely take more than a few minutes.

Background services run with Prefect for workflow orchestration, and asynchronous communications between applications use BullMQ with Redis as the message broker. For real-time features, I use Socket.IO with Redis adapters to support scaling. Currently, Deeditt costs me not more than $150 USD monthly, and that's enough to support a few hundred more users before needing to scale.

🔀 The Challenge of Service Communication

One of the most complex challenges was establishing communication between different micro-services and servers. With Docker Swarm orchestrating several nodes, I had to make difficult decisions about how to distribute limited resources most efficiently.

I implemented an internal API gateway pattern where each service communicates through a central orchestrator that handles routing, authentication, and rate limiting. This reduces point-to-point communications and simplifies the overall architecture. Since everything runs under Docker Swarm, I don't need additional service discovery tools - the built-in networking handles service location efficiently.

For data consistency across services, I implemented an event-driven architecture using a message queue system. When a service makes a state change, it publishes an event to a topic that other interested services subscribe to. This maintains eventual consistency without tight coupling.

I had to write several custom rules to ensure stable connections between containers. Nothing overly complex, but certainly delicate. This is where my previous experience with distributed systems proved invaluable. I could have started with more sophisticated methods, but maintaining them would have been a headache I wanted to avoid at this stage.

🧩 The Hidden Complexity Behind Simplicity

There's a whole world of complexity beneath Deeditt's surface that users never see. For example:

Internationalization: While Deeditt is prepared for multiple languages, I've currently implemented 6 languages in the frontend and 2 in the backend. The infrastructure is ready for full localization including time formats and cultural contexts, but it's not completely set up yet.
Content Caching: What appears real-time actually involves caching systems with slight delays, optimizing the balance between immediacy and server load. User feeds are cached with intelligent invalidation to ensure content stays fresh.
Security Layers: Multiple security systems work together to protect user data and ensure platform integrity, from authentication to data validation.
Recommendation Engine: I'm working on a system that suggests relevant content and connections based on user interests and behavior patterns. It's still a work in progress, but even in its early stages, it helps users discover content they might find valuable.
Interface Complexity: The UI might resemble Twitter or Threads at first glance, but once inside each "deed," there's a different world of options to discover—creating this intuitive complexity was one of the toughest design challenges.

Each of these elements taught me something valuable, both technically and about user expectations. The most elegant solutions are often those the user never notices are there.

🔄 Deployment and Recovery: Versions, Environments, and Pragmatism

I work with three branches (dev, staging, production). Since my budget is limited, my sandbox is very restricted and shares some resources with production plus a local mix, which forces me to be careful, but it works.

To stay organized, I use Linear for project management, and each ticket number becomes a branch name. This approach clearly helps me identify what I'm building and keeps my work focused. Once a feature is ready, it gets merged into dev. This simple system creates a clear connection between planning and implementation that's invaluable when working solo.

Each deployment is linked to a version tag, both in GitHub and Docker Hub. If something fails, I rollback to a previous stable image. My deployment strategy ensures minimal disruption when updating services, with health checks confirming stability before completing the transition.

For smaller projects, this level of organization might seem excessive, but when managing multiple micro-services and a growing feature set, having this structured approach to deployment and recovery has saved me countless hours of troubleshooting.

🧠 Technical (and Not-So-Technical) Learnings

One of the first systems I implemented was a scoring algorithm with many rules and a popularity system based on multiple factors. It considered interaction patterns, content quality, and user engagement signals to determine what should be shown in feeds.

But over time, I realized I had over-designed things that actually needed to be simple. I refactored the system to focus on just a few core metrics, which resulted in both better performance and more intuitive results for users.

I also spent many hours creating monitoring dashboards. I tracked everything from resource usage to user engagement patterns. But eventually, I understood I was optimizing things that didn't yet need attention. In early stages, less is more.

Have you spent hours optimizing something that didn't really need optimization at that moment?

If I were to go back, I would simplify. Not everything needs to be perfect from day one. Sometimes, "good enough" is exactly what's needed.

In retrospect, developing such comprehensive metrics at an early stage was premature. Although it gives me visibility into the platform, that time could have been invested in features more important for attracting users.

🔑 The Unique Value: Journeys as a Differentiator

What truly distinguishes Deeditt from other platforms are "Journeys". While other social networks show isolated moments, Deeditt allows grouping related "deeds" (achievements/actions) that together tell a complete story over time.

Technically, Journeys are implemented as a flexible structure where each journey can contain multiple deeds, and journeys can also connect to other journeys. This creates a way to organize content that mirrors how real experiences are interconnected.

Each deed within a journey can include images, videos, hashtags, and mentions of other users. Additionally, you can configure privacy settings and define who has access to specific journeys and deeds through customizable visibility policies.

This approach solves a silent but critical problem of our time: the difficulty of verifying if someone really has the experience they claim. By seeing a complete story with all its parts, including obstacles and failures, you get an authentic context that traditional platforms don't offer.

And like many things we do in life, we're always involved in more than just one thing. I'm a clear example—while writing about the development process of Deeditt, I also share thoughts about my son, my journey learning open water swimming, some health issues, and other topics. Each of these is separate, without needing to share too many personal details—just a general view of the moment I'm going through.

The most beautiful part so far is that search engines are already starting to discover the content being created on Deeditt, and that means a lot of positive things.

🌪️ The Real Challenge: Users, Community, and Visibility

None of this matters if nobody uses it.

And there's the real challenge: building community. I returned to social media after years away, only to discover that organic marketing, content, and interaction are completely different worlds from distributed systems and CI/CD pipelines.

On platforms like Medium, I encountered the usual problem: algorithms that don't show what you write if you're not "playing the game." Claps, reads, comments... nothing seemed to have consistency. On LinkedIn, I saw an avalanche of "perfect posts" where everyone is successful, brilliant, and unstoppable.

Deeditt doesn't want that, Deeditt wants the journey, the stumbles, the questionable decisions, the discarded versions.

And of course, that's not easy to sell.

👂 What I've Learned from Feedback

User feedback has been revealing. many get excited about the concept, suggest features, and celebrate updates... but then don't actively use the platform.

This paradox—the gap between what people say and what they do—has been one of my biggest learning. By tracking feature adoption and identifying drop-off points, I discovered that while users loved the concept of Journeys, the friction of creating them was too high.

I'm using that behavior to adjust the experience, but I'm doing it calmly. I want to listen more than I assume, and I'm prepared to change whatever is necessary.

💬 Breaking the Technical-Human Barrier

Perhaps the most unexpected challenge has been learning to express myself effectively. As a developer, I was used to communicating with computers, not people. Marketing, clear communication, and emotional connection are skills I've had to develop from scratch.

It's ironic: I created a platform to improve authentic communication, and in the process, I'm learning to be more authentic in my own communication.

✋ To Those Who Haven't Started Yet: Don't Wait for Everything to Be Figured Out

If you're reading this and haven't started your project yet because you're waiting for your idea to be ready or the stack to be perfect, I'll tell you honestly: it won't be.

Start with what you know. Adjust along the way. Nothing is definitive. I've modified many parts I thought were immovable. Building is iterating, and if you can share what you experience, even a little, you're doing something much more valuable than it seems.

If you have an idea, start it and don't wait for it to be perfect, don't wait to have everything clear. You'll solve things as you go, and what seems like a great solution today might not be tomorrow. That's okay. That's what building is about.

Before Closing

I'm still building Deeditt. I'm still writing about its evolution under the title "Building Deeditt" I don't know when it will grow, or how many people will use it. But I do know that every line of code, every adjustment, and every decision is made with purpose.

What I want to convey is that building solo is possible—even rewarding—but requires balancing technical and human skills. You don't need to spend fortunes on cloud services to create something valuable, but the time you invest is perhaps your most precious resource.

I continue working on Deeditt because I believe it makes sense, even if growth is slow. I do it because I want there to be a place where we can show our processes—without fear and without embellishment.

In the end, it's about creating spaces where we can all grow, share, and learn together.

If you're curious, I invite you to take a look at what I've been building. I'm always eager to hear others' stories—feedback, good or bad, is always welcome. And if you're feeling a bit tired of traditional social media, I propose a different model for sharing content. One where you don’t need to chase validation or constantly post something flashy. I call it "slow content"—a way of publishing that encourages you to write only when you have something meaningful to share, something that adds value to your knowledge and might resonate with others.

And if you're also building something, I'd love to hear your story on Deeditt—or tell me in the comments.

How do you deploy your applications?

Jackfiallos — Sun, 17 May 2020 10:13:12 +0000

Usually I use Mina and Codeship and before Capistrano and Jenkins but I'm interested of knowing what you people use to deploy your applications. Comments and links are very welcome.

Cheers!

Create your own tunnelling like ngrok does

Jackfiallos — Wed, 19 Feb 2020 18:36:48 +0000

If you're here is because you don't want to use ngrok or you are looking for an alternative to it, which is pretty valid because if somebody did that, why you don't?

Well, this story begins with me trying to make my local development environment public and here is where ngrok came to the rescue, this tool works really well, but with some limitations, like having a random subdomain every time you restart your application or using more than one connection, are the things you will need to deal with unless you don't pay for it.

So basically everything works behind ssh tunnelling connections, and if you want to create your own ngrok clone, mainly you will need a VPS server running Linux preferentially.

Now try to connect your local computer to the VPS server through SSH (111.111.111.111 in this case).

$ ssh root@111.111.111.111

There are some different ways to get this done, every connection string depends on the service provider you're using, could need to type your password or could be using a .pem key but in the end, will have the same result.

With your VPS session opened, just type the next command in your terminal, if you have issues with this command try to open the sshd_config file and write at the very end "GatewayPorts yes".

$ echo "GatewayPorts yes" >> /etc/ssh/sshd_config
By default, OpenSSH only allows connecting to remote forwarded ports from the server host. However, the GatewayPorts option in the server configuration file sshd_config can be used to control this.

Restart the SSH service and exit from your session

$ service ssh restart
$ exit

Now you should be able to run a command similar to this one, and guess what!!

$ ssh -R 8080:localhost:3000 root@111.111.111.111

Voilá, this will open the port 8080 on the VPS server and will forward it to the port 3000 on our local machine, basically means you can type on your browser http://111.111.111.111:8080 and effectively will redirect the traffic to your local computer.

I know you want more, say.. subdomains and https connections? yeah, why not, let's finish this.

The next part of this mini how-to is creating a subdomain and link it with your public VPS IP, but I'm will leave this to you, again .. this depends on what service provider you're using.

At this point, you have your VPS server running and ready to forward from source to destination ports, let's assume you have your subdomain created as well, now the next step will be setting up your web server with a reverse proxy tweak. In my case I decided to use Nginx, it's my favourite and it's really simple to set up, actually, my current configuration is similar to this:

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    server_name _;
    location / {
        proxy_pass http://127.0.0.1:8080;
    }
}

And again, works! my VPS server receives traffic from my subdomain and redirects to 127.0.0.1:8080 which is the same server but through SSH tunnelling.

If we test again typing in the browser address bar http://yoursubdomain.domain.com should work and redirect again all petitions to your local computer.

This still needs to work with SSL and to complete this step I recommend you to install certbot and follow the instructions, it's pretty straight forward so I don't have a doubt you will get it.

This is my first article as a non-native English-speaker, so be kind and patient.

Happy Coding! :D