DEV Community: Bladimir

The Golden Project: The One Demo That Serious Software Engineers Should Have In Their Portfolio

Bladimir — Thu, 05 Mar 2026 13:22:27 +0000

Some Software Engineers, specially when starting their careers, struggle having substantial projects to showcase since they just graduated from School and may only built 1-2 academic projects and have covered the theorical part of the IT field; similar situation occurs with self-taught developers. Even worse, there are scenarios in which there is nothing to show for it.

In my case, back in the days I had some GitHub repositories that represented my portfolio of work related to generic already-known solutions to problems. They were built just to acquire technical skills, learn a new framework, pick up a programming language, be caught up with some related technology and acquire some hands-on experience. After a while, I realized that each of those software projects were too basic in terms of structure and organization which didn’t help much when preparing for job interviews that include a portfolio review, or to show it to a potential client.

The Problem with Toy Projects

One of the main problems of having just simple CRUD apps in the portfolio is their lack of structure and purpose. It is true that they perhaps can be used to demonstrate knowledge about a specific concept or enhance a skill, but this is not enough because in almost all cases they get thrown away and maybe left unfinished; unless someone develop them as a hobby while exploring new technologies or basic concepts.

The main goal of a serious engineer should be building to learn. By learning, I mean “active learning”, which is different than just following tutorials or doing courses over and over. So, when developing a software project for demo purposes or diversify the portfolio it is important to apply the appropriate strategies in order to create something substantial so that it doesn’t feel the time was wasted. That is the “Golden Project”.

What is a Golden Project?

A Golden Project is the best single production-grade personal demo which is polished, well structured, and a software anyone would use in real life. It demonstrates the full capabilities of a Software Engineer during the whole software lifecycle, from analysis and architecture to deployment and documentation. It can be considered a project that one can be proud of, like a lethal weapon for interviews, showcase to potential clients and other career opportunities. It is a work done with care.

While some new software engineers don’t even have a single app to present, others publish around 5-7 small toy projects or CRUD apps to highlight a portfolio of demos that just fulfill content into their resumé when preparing for jobs; only few developers own solid demos. The major downside with this approach is that hiring managers when analyzing candidate profiles they immediately notice that these kind of projects just do not click and then quickly decide not move forward in a job application. Same happens when you try to present your previous work to new leads. So, a Golden Project solves all these issues by demonstrating the fundamental real skills and professionalism; more importantly, when done right, it shows determination and persistense.

Toy vs. Golden Projects

Toy Project: too simple, lacks of architectural and coding structure, sometimes considered throw-away experiments. Mostly built without a real purpose, just for job hunting.
Golden Project: complex, robust, shows well-defined planning, organization, architecture, reliable similar to a production-grade level. Built with a goal in mind.

What Makes a Software Project “GOLDEN”?

It is not about the bunch of trendy technologies or fancy tools you use. Everything relies on the motivation behind it and the standards applied throughout. It should have the following characteristics:

It solves a real problem, it is not a project implemented with random ideas or unknown scope. It must have a reason to exist.
It follows best software practices, meaning it is crafted applying the highest possible standards to make it highly valuable.
It is live and works properly, even if no one uses it, it is built as it would be used in real life so every possible error is handled properly following best practices. The users can explore its functionalities and provide feedback.
It is relevant to the field, realistic, secure. It complies with the fundamentals security standards, even as a demo, similar to a production-level project.
It includes the decision-making of relevant parts, meaning not implementing features just for the sake of learning a particular framework or tool. The process of building a Golden Project should emphasize why a decision was made, it demonstrates architectural thinking.
It is well documented, so it’s easy for anyone to understand by including detailed instructions, descriptions and images.

Is It Worth It?

Beginning to build a project of that magnitude could be intimidating at first because it is not something you can produce in one day, but in the long run it will be worth it. Obviously, when developing these kind of projects, there will be a lot of challenges and difficulties that certainly will arise. But there is an important takeaway, when you try to find a way to solve a particular problem and stay persistent especially in projects that big and complex, you’ll learn more than just following a happy-path tutorial. Not only does it give you a rewarding learning experience when finishing it, but also teaches you valuable things such as commitment, discipline and professional growth. Plus, you’ll own it forever and can be used as reference for other project ideas, or inspire others.

Right now I’m in the middle of building my own Golden Project which is not live yet, but I’m polishing every aspect of it so it fullfil the minimum criteria that simulates a real production software. As soon as it’s ready I’ll drop the link here and show the results.

If you already have or think to build one and want to share the details, you can share in the comments below, so I can give feedback.

That’s it. I’ll end this post by adding this remark:

| The hardest part of a journey is starting. Once you begin, the rest gets easier.

Thanks for reading.

If this article helped, share it with anyone in the field who’s stuck building toy projects!

Building a Secure Demo Banking App [Part 2]: Implementing the First Microservices

Bladimir — Thu, 22 Jan 2026 17:25:24 +0000

REVIEW FROM PART I

In part I, I outlined the scope, architecture and overall project structure and some of the initial features for the DemoBanking App.

Initially, while exploring the API Gateway layer, I considered AWS API Gateway to be integrated due to its convenient features. However, after hitting some roadblocks regarding the AWS costs and maintenance for a demo project I decided to go for Spring Gateway. Even though AWS offers a generous 12-month free tier, I’d already used mine for other hands-on labs and experimental projects.

From the bright side, choosing Spring Gateway makes everything inside Spring ecosystem which eliminates extra configurations for making things compatible between two vendors tools. Also, it allows anyone that clones the project repo to run the app without this limitation.

TECHNOLOGY STACK:

Frontend: React, TypeScript, Tailwind CSS.
Backend: Spring Framework (Boot, Data, Gateway)
Database: PostgreSQL (for user, account and transaction microservices)
Authentication: OAuth2 / OpenID Connect
Observability: Apache Kafka, Prometheus, Grafana, OpenTelemetry, ElasticSearch

Project Structure (so far)

demo-banking-app (project root)
/docs
/observability
/tests
/docker-compose.yml
README.md
pom.xml
/services (detailed below)

Inside /services directory, the user, account and transaction microservices follow a similar structure:

/controller: it handles the relevant API endpoints.
/dto: as the acronym suggests, it is for managing “data transfer objects” without touching the JPA entities directly.
/entity: it represents the entity class for each microservice.
/repository: responsible for interacting or communicating with the database source using the Spring JpaRepository.
/service: this is where all the business logic is handled.
/exceptions: this will contain the classes for handling exceptions (pending to be implemented).
/utils: it includes any utility or common classes such as mappers to “map” from an entity to DTO, and viceversa.

MICROSERVICES

As I mentioned before, there are three microservices implemented at this stage so far.

Microservice #1: User

It is considered to be one of the core microservices of the project since it is responsible to manage everything related to users.

Key endpoints:

8081/users
GET 8081/users/all
GET 8081/users/{id}
POST 8081/users/create
PATCH 8081/users/update/{id}
PATCH 8081/users/disable

Microservice #2: Account
Similarly, the account microservice handles every aspect related to bank accounts in this demo project.

Key endpoints:

8082/accounts
GET 8082/accounts/all
POST 8082/accounts/create
GET 8082/accounts/{accountNumber}
PATCH 8082/accounts/update/{accountNumber}
PATCH 8082/accounts/inactivate/{accountNumber}

Microservice #3: Transaction
Finally, there is the transaction microservice which handles the bank transactions.

Key endpoints:

8083/transactions
GET 8083/transactions/all
POST 8083/transactions/create/{type}
GET 8083/transactions/{id}
PATCH 8083/transactions/cancel/{id}

DOCKER SETUP: RUNNING LOCALLY WITH DOCKER COMPOSE
In order to make the project easy to run without manual configuration difficulties, the initial version uses a single docker-compose.yml file at the root. This will handle:

The Spring Cloud Gateway (entry point, which is pending to be implemented)
The three implemented microservices (User, Account, Transaction)
A PostgreSQL instance (with separate schemas or databases per service)

Each microservice has its own Dockerfile located in the root folder, using a multi-stage Maven build for efficiency:

1. Build stage: Compiles the Spring Boot JAR with dependencies.
2. Runtime stage: Copies the slim JAR into a lightweight OpenJDK/JRE image.

Quick start commands (which is also included in the README):

Clone
git clone https://github.com/blad90/demo-banking-app.git

Build and start all services + DB
docker compose up -d --build

Check logs for one service (e.g., user-service)
docker compose logs -f user-service

Stop everything
docker compose down

CONSIDERATIONS AND REFINEMENTS

Saga Pattern (orchestration vs. choreography):

It is important to mention that initially, since the Saga Pattern was the design choice for the software architecture I analyzed which would be more appropriate for the project between the orchestration and choreography approach. While exploring about the two regarding the advantages and disadvantages according to the project scope, I concluded the Saga Orchestration is the right selection for the following reasons:

It uses a main orchestrator, where it centralizes all the communications between microservices.
For the level of complexity that will take this demo-banking application as it evolves, it facilitates the debugging process when anything goes wrong.
The choreography approach may not fit in this project well since communication happens among microservices themselves, which could be a headache when the application grows in complexity.

Relationships between entity models

When completing the initial versions of each microservice (User, Account and Transaction), I started to wonder about how could be appropriate to handle the relationships among entities. For example, when Account requires to be linked to an User.

Based on previous experiences in developing monolithic applications, for instance the ones based on Spring, I know that it is straightforward establishing relationships using JPA annotations to represent entity cardinalities such as @OneToMany, @OneToOne, and so on. However, when building more complex applications, specially those with an architecture based on microservices, I started to notice that it wasn’t the right approach because of the following:

If two or more entities from distinct microservices references to each other, it produces a tight coupling issue.
It is hard to maintain in the long run if entities or components tightly coupled.
Tight coupling affects the microservices autonomy.

As a result, while exploring and researching alternatives, the event-driven cache updates pattern came into play, which is great for performance and resilience in complex, distributed systems such as banking applications. This pattern allows data sharing between services through events keeping microservices independence. Each service keeps a cache version of the data received from another service. For instance, Account microservice stores User data on its own database schema, which is a cache version received from the User microservice, without impacting its database.

Below is the updated architecture diagram, mostly about the switch between AWS API Gateway to Spring Gateway mentioned in the “Review from Part I” section:

Original version

Updated version

WHAT’S NEXT?

I’ll prioritize to complete the pending tasks and then add new features based on the actual architecture. It includes:

Exception handling and validation for each of the implemented microservice in this stage.
Implement the API Gateway.
Apply the event-driven cache updates pattern for communication among relevant services, using Apache Kafka.

For more

Follow along on X [@bladbaez], I’m open to feedback, suggestions or anything else.

Building a Secure Demo Banking App [Part 1]

Bladimir — Tue, 06 Jan 2026 21:04:30 +0000

When building software projects or applications, it is important to be aware of how quickly technology evolves over time. For development, it is said that some tools or programming languages get updated at most each six months approximately; so that we need to catch up with newer versions that may introduce new patterns or concepts, otherwise we fall behind.

However, no matter how fast technology changes, the foundational core concepts of software development almost always stay the same. Now, with the revolution of AI, generic and simple software projects, such as CRUD apps, don't add the substantial value that we, as Software Engineers, expect to get in terms of knowledge and critical thinking. In order to build something powerful and reliable it should follow the best coding and security practices in each phase of the development cycle.

Why the Demo Banking App project?

I decided to build a software related to fintech, for demo purposes, based on the following reasons:
It deepens my skills in Full Stack mostly used in Fintech.
It represents a substantial software application for portfolio, that can be showcased publicly. The whole planning, development, deployment, I called it as "The Golden Project", since it covers almost all the grounds in terms of planning, coding structure, security, architectural and design patterns, as well as CD/CI. For simplicity, the name of the software application will be "Demo Banking App".
I plan to document each important feature and component to reinforce my understanding and adapt my approach as roadblocks arise throughout the build.

Project Goals & Scope

The first version of the "Demo Banking App" will include features noted below:

User registration and authentication
User profile
Account dashboard
Transaction history
Payments
Notifications
Fraud-screening

Technology Stack

While deciding the stack to choose for this kind of software project, I took into consideration the relevance and usage in real-world fintech apps, previous experience with some technologies and tools, and relevance of today's software best practices. Below the breakdown of the stack:

Frontend: React, TypeScript, Tailwind CSS.
Backend: Spring Boot
Database: PostgreSQL
Authentication: OAuth2 / OpenID Connect
Observability: Prometheus, Grafana, OpenTelemetry, ElasticSearch

Architecture

The architecture pattern to be applied is based on microservices and the Saga Pattern. The reason behind this choice is due to the project complexity in order to ensure escalability and smoothness of all transactions, simulating a real-world banking app.

Security from the Beginning

Even though it is a bank application for demo purposes, it is crucial and important to apply the best security practices. For version #1, some of them include:

Using environment variables instead of plain-text values
CORS restriction
Rate limiting on login routes
Input validation
Password encryption

Logo and Colors

I designed the logo of the demo banking app in a simplistic way to emphasize minimalism and highlight the realistic corporative touch.

The colors, intended to be used as color scheme for the whole app, were inspired by a German neobank.

What's next!
I will post about the project progress as important features are completed.

To reach me out:

Follow me on X (@bladbaez)
Website/blog (BLADBAEZ.COM)