Almost 10 years ago, I was a Java developer working at a large company in Belarus. I spent my days writing enterprise code, and my free time building small Android apps or hobby websites.
My brother had spent his entire career in the plumbing business—managing warehouses, retail sales, and installations. He knew the industry inside and out. I knew Java inside and out. After some discussions we decided to launch an online store.
It seemed simple enough. I'd get to practice my web development skills, and if it failed, at least I'd have learned something useful for my day job.
The Stack Decision Nobody Understood
When I told people I was building an e-commerce site from scratch in Java, they looked at me like I was crazy. "Why not use Shopify? Or WooCommerce? Or literally any existing solution?"
The logical choice would have been PHP with an existing CMS like WooCommerce or PrestaShop. They're battle-tested, free, and have thousands of plugins. But I had concerns:
- I didn't know PHP well enough - Learning a new language while building a business seemed risky
- Control and understanding - I wanted to know exactly how every part of the system worked, not just configure it
- The "black box" problem - With existing CMS platforms, you're often limited by what plugins exist and how they interact. Debugging issues means diving into other people's code
- Learning opportunity - Even if the business failed, I'd gain valuable Java web development experience for my career
So I made the unconventional choice: build everything from scratch in Java.
The Technical Architecture
I built santego.by using:
Backend:
- Spring Framework - The obvious choice for Java web development. Reliable, well-documented, and I already knew it
- PostgreSQL - Rock-solid relational database, perfect for e-commerce with its ACID guarantees
- Lucene - For fast, flexible product search without needing Elasticsearch or other heavy solutions
Frontend:
- Server-side rendering with Pebble Templates - Not an SPA, despite the trend
- Bootstrap - For a clean, responsive design without hiring a designer
- Minimal JavaScript - Just what was needed for interactivity
Why Server-Side Rendering?
This deserves its own explanation. In 2017-2018, SPAs were all the rage. React, Angular, Vue - everyone was building JavaScript-heavy frontends.
I chose server-side rendering because:
- Simpler SEO - Search engines could crawl everything immediately
- Faster initial page loads - No waiting for JavaScript to bootstrap
- Less complexity - One language ecosystem, not two
- We wanted a minimalist site - No need for complex client-side state management
For an e-commerce site where SEO matters more than interactive widgets, this was the right call.
The Choices I Regret (and Don't Regret)
Don't regret:
- The tech stack - it's proven stable and maintainable over 8 years
- Server-side rendering - still the right choice for our use case
- PostgreSQL - never once regretted this
Do regret:
- Not hiring a designer initially - Bootstrap templates only get you so far, especially on mobile
- Some architectural decisions made in haste that became technical debt later
Looking back, the technology choices were solid. But there were plenty of business things I got wrong.
The Mistakes We Made (And What They Taught Me)
Mistake #1: Thinking "Build It and They Will Come"
We launched the site, listed products on marketplaces, and waited for sales to roll in.
They didn't.
Eventually, we realized we needed advertising. We started with Yandex Direct, then Google Ads. The learning curve was steep—we spent weeks tweaking campaigns to reduce bounce rates and optimize click costs.
Lesson learned: Being a good programmer doesn't make you a good marketer. You need both.
Mistake #2: Ignoring Analytics
For too long, we didn't have proper analytics in place. When we finally integrated Yandex Metrika with Webvisor (which records user cursor movements), we discovered dozens of small UX issues we never knew existed.
We also weren't appearing in search results because search engines didn't even know about most of our pages. After adding a sitemap and fixing broken links through Yandex Webmaster and Google Search Console, we finally started getting organic traffic.
Lesson learned: Install analytics tools on day one, not day 100.
Mistake #3: Bad Domain Choice
We spent so much time making sure "santego.by" sounded good in both Russian and English that we forgot to consider length. A shorter domain would have been easier to remember and fit better in logos and small banners.
Lesson learned: Simple and short beats clever and memorable.
Mistake #4: Building Features Nobody Used
Over four years, I added countless features in my spare time: filters, sorting, video uploads for products, delivery sheet printing, and much more. I made everything configurable through an admin panel.
But many features went unused. We wasted time on things customers didn't care about while neglecting things they did.
Lesson learned: Talk to users before building features, not after.
The Turning Point
After years of modest growth, competition intensified and profit margins shrank. We realized we couldn't compete by being everything to everyone.
So we made a tough decision: narrow our focus to only what was profitable.
That's when we created gappobel.by - a new store selling just one brand.
The SEO Discovery That Changed Everything
Something unexpected happened after launching gappobel.by: it started ranking much better in search results than our original multi-category store. A focused, single-brand store was naturally easier for search engines to understand and categorize.
This wasn't just theory - we saw real results. Better rankings meant more organic traffic, which meant lower customer acquisition costs.
That discovery led us to launch frapbel.by, another single-brand store following the same proven model.
Building Store #2 (and #3): The Streamlined Approach
The new stores are optimized versions of the original platform, adapted for single-brand sales. We:
- Updated the design
- Removed unnecessary features
- Kept the same proven tech stack (now with the latest Java version and Spring Boot)
- Maintained full independence from third-party services
Our only recurring cost is hosting with 4GB of RAM. No monthly SaaS fees, no vendor lock-in, complete autonomy.
Yes, our platform still has less functionality than free PHP CMS options. But it's fast, SEO-optimized, and perfectly suited to our needs. After five years, that's all that matters.
The Unexpected Side Effect
When I published my first article about building an e-commerce store in Java, it barely got any attention—a few likes, a couple of comments. But over time, it started ranking well in Google for "e-commerce store in Java."
Then something interesting happened: I started getting messages from developers who also wanted to build e-commerce sites in Java. Some asked me to build stores for them. Others wanted to buy the code. A few suggested I turn it into a framework for Java-based e-commerce.
I never pursued those ideas, but it showed me there are more Java developers out there who want to build their own solutions rather than use off-the-shelf platforms.
Would I Recommend This Approach?
Honestly? It depends.
Don't build from scratch if:
- You need to launch quickly
- You don't have deep technical expertise
- Your business model is still unproven
- You don't enjoy maintaining code
Do build from scratch if:
- You want complete control and customization
- You're comfortable with the long-term commitment
- You enjoy learning by building
- You hate paying monthly SaaS fees
- You want to own your entire stack
For me, building in Java was never just about e-commerce. It was about proving I could build a real business application from scratch, learning every aspect of the problem, and having full autonomy over the solution.
What's Next?
Will we build more stores? Yes, definitely. Will we turn this into a framework or product for other developers? Potentially, if we spend enough time on polishing it, we want to publish it on github so other Java developers will be able to use it.
Tech Stack Summary:
- Java (latest version) with Spring Boot
- Pebble Templates
- PostgreSQL
- HTML + jQuery frontend
- Bootstrap theme
- Lucene for search
Top comments (0)