Hello! I’d like to share a short story about how I’m building my website—what tools I use, what I avoid, and the lessons I’ve learned along the way. I don’t claim to have all the answers; I have about four years of development experience and I’m always open to feedback from more seasoned engineers. I hope this post is useful for beginners—and also helps get my project in front of people who might find it interesting.
0. Idea
To get started, you need an idea. With so many apps already out there, it’s hard to invent something truly unique—especially something a solo beginner can realistically ship. But it’s not impossible. There’s always room for improvement: somewhere there’s too much advertising, somewhere there are rough edges, and elsewhere there’s a missing tool or a clumsy UX.
Sometimes, you can just build what you want to see in the world. That’s how my project began. Alternatives likely exist and may be more polished, but I wanted to make this site myself.
The site’s core idea:
- put all a user’s social links and forum profiles in one place to make sharing easy;
- keep the profile free of advertising so it looks clean;
- offer broad customization options;
- provide widgets that present personal info nicely—from birthdays to integrations with services like GitHub;
- let beginner developers and designers publish themes and earn a little money.
1. Monetization
Monetization is a popular question. There are many approaches, but the key is to be clear about what users are paying for. The product should not only solve a problem, but also be likable.
This topic deserves its own articles; here I’ll outline how I think about monetizing my site. Infrastructure costs are modest, so the project can run on donations and small purchases. I don’t plan to restrict widget functionality—most will be free. So what do we monetize?
1.1. Themes (Appearance)
Not everyone wants to configure everything from scratch. Ready‑made themes save time and simplify onboarding. Of course, there will also be free options so no one feels limited.
1.2. Usernames
This idea is inspired by Telegram—without the resale problem. Short usernames are easier to read, remember, and type. I realize “ownership” can be contentious, so I’ll make decisions as transparently and fairly as possible. For example, protecting the names of well‑known brands from impersonation, and helping promising projects by reclaiming names from inactive accounts.
I also plan to share revenue stats for the project later on.
2. Setup Tips
These are not universal rules—just my experience. Yours may differ.
2.1. Operating System
I’ve used Windows (7/10/11) and Linux (Ubuntu, Arch). I’d recommend Linux even to beginners: it gives you valuable experience and eliminates many issues (while adding some new ones—usually temporary). I’m currently on Ubuntu 25.04. There’s a huge selection of software via APT, Snap, and Flatpak. Linux hasn’t been “terminal only” for a long time—it’s worth a try. Dual‑booting is also an option and can be resource‑friendly.
Working on Linux at home helps you understand servers more easily. I also appreciate the file systems Linux offers—but that’s a topic for another post.
2.2. IDE / Code Editor
My editor of choice is Visual Studio Code—an excellent tool with a vast ecosystem used by both beginners and pros. I use the VSCodium fork—not so much for disabled telemetry as for the convenience of separating different projects across different editors.
2.3. Consistent Code Style
Set this up early: Prettier and a linter (e.g., ESLint), and in my stack—Husky to run checks before committing. Editor plugins make these tools even smoother. If you work with a partner or a team, consistency becomes critical.
3. Frontend Technologies
3.1. Framework
I’m primarily a backend developer, but here’s my frontend take. I chose Vue. If SEO is a priority, server‑side rendering (e.g., Nuxt, which is also Vue) makes sense, and you’d be right to consider it.
In my case, page generation lives on the backend, and Vue powers the interactive site. I’ve worked with both Vue and Nuxt; they’re similar enough that for the beta I stuck with Vue. I may migrate to Nuxt later.
3.2. Components
I’ve tried many libraries, and my favorite is PrimeVue: a large component set with strong customization. (They also offer PrimeBlocks and PrimeFlex for layout.) There are minor visual details I don’t love, but they’re easy to fix with custom styles.
Ready‑made components save time on common UI (Switch, Select, Calendar, etc.), which is ideal for beginners while aligning with UI/UX expectations.
3.3. Icons
I use Iconify (@iconify/vue)—a single interface to a huge collection of icon sets. Very convenient.
3.4. Fonts
Two main options: Google Fonts or Fontsource. I prefer Fontsource since fonts install as npm packages and fit nicely into the build.
3.5. Styles (CSS)
My choice is Tailwind CSS (v4). It removes the need to name every div and reduces context‑switching into separate CSS files (though editor plugins help with that as well). Highlights include a rich color palette, handy modifiers for dark mode (dark:), states (hover:), and responsive breakpoints. For most sites—especially early on—this is more than enough.
3.6. Other
For default profile backgrounds I use tsparticles—a fork of particles.js—to create an interactive network of particles that connect into interesting shapes.
For random name generation I use @faker-js/faker. For typewriter and counter animations: vue-countup-v3 (based on countup.js) and vue3-typed-ts. You can also look at anime.js and @vueuse/motion.
For backend requests I use openapi-fetch. I’ll return to this in the OpenAPI section.
4. Backend Technologies
Here the bar is higher: security, performance, scalability, and more. Each of these topics could fill a series of posts, so here’s a concise overview of my choices.
4.1. Programming Language
High‑ or low‑level depends on your goals and ecosystem. I choose TypeScript: I like the syntax and type safety. I also use TS on the frontend. I’m not a fan of overly complex types—basic constructs usually suffice, and type safety helps you sleep better.
For the runtime I use modern Bun instead of Node.js. Practical advantages include:
- near‑full compatibility with Node.js;
- strong performance;
- the ability to run TS files directly;
- a rich standard toolkit (fs, crypto, etc.);
- hot reload and partial module reloads;
- packaging the app into a single executable.
4.2. Framework for REST APIs
I use Hono. Why I like it:
- many useful features out of the box: CORS, logger, rate limiting, etc. (with Express you often add them as separate packages);
- in my tests Hono was faster than Express; combined with Bun this yields a nice performance buffer;
- straightforward OpenAPI integration via
@hono/zod-openapi, giving you typing and validation during development.
4.3. OpenAPI
Instead of manually maintaining Postman collections, I use OpenAPI and @scalar/hono-api-reference for modern, generated docs. For frontend integration—openapi-typescript and openapi-fetch.
Benefits of this stack:
- built‑in validation (via Zod in my case);
- automatically generated, always up‑to‑date documentation;
- strong typing on the backend;
- types on the frontend that update alongside the API (no duplicated interfaces);
-
openapi-fetchis lighter and faster than alternatives like Axios.
4.4. Database and ORM / Query Builder
I originally planned PostgreSQL, but for speed I started with MongoDB + Mongoose. For this kind of project a non‑relational DB is a compromise: not perfect for optimization, but fast to iterate. I’ll likely migrate to PostgreSQL with Kysely (a TypeScript‑friendly query builder inspired by Knex). A big plus of Kysely is typed database schemas: once described, your tables and fields are discoverable right in code. Many ORMs offer similar features, but I prefer a more minimal approach.
4.5. Page Generation
User profiles are rendered with happy-dom, giving me a lightweight SSR. For OpenGraph banners I use Playwright: instead of custom canvas drawing, I write familiar HTML/CSS (Vue, Tailwind, and friends are all available).
5. Deploy (a Bit of DevOps)
Getting code into users’ hands is the trickiest part for beginners.
5.1. Versioning
Git is non‑negotiable. I used to struggle with commit messages, and maybe you do too. AI can help draft them now, but it’s still worth knowing the basics—see Conventional Commits.
5.2. Containerization
The main benefit: consistent behavior across environments, plus extra isolation on the server. Most often this means Docker.
5.3. CI/CD
After pushing to GitHub / GitLab, a pipeline should ideally run type checks, linting, tests, build, and deploy. If you use PostgreSQL (or similar), include migrations.
Full disclosure: for the alpha I skipped the first two steps because I’m working solo. I’ll set them up later. I currently use a bare Git repository and custom bash scripts. It may look like reinventing the wheel, but my code and server keys stay exclusively with me—no need to host my own GitLab/Gitea.
5.4. Nginx
This may be overkill for beginners, but I run two servers with the future in mind. One is public and runs only Nginx (and could act as a load balancer later). The second is private and hosts the API, database, and other services. They’re connected via VPN (WireGuard), which lets me avoid certificates between internal services. I considered self‑signed certs and Caddy, but VPN was the quickest and most convenient choice for me.
5.5. DDoS Protection
I recommend adding Cloudflare. My project isn’t popular yet, so I haven’t enabled it; I’m also curious about alternatives—and even building something myself for learning’s sake.
6. Domain
6.1. Purchase and Setup
I like Namecheap—they support DNS‑01 (useful in the next step), have reasonable prices, and offer “Beast Mode” for bulk domain search.
6.2. SSL Certificate
I use Certbot with the Nginx plugin to obtain free Let’s Encrypt certificates. I configured auto‑renewal for the site and API and plan to renew the wildcard certificate manually. For that you need DNS‑01—see Let’s Encrypt’s docs on wildcard certificates.
7. What’s Next
The hardest part is growth. I understand the mechanics, but I don’t have a widely popular project yet, so I won’t pretend to teach growth hacking. My only advice: consistently share what you’re building. The platform matters less than the habit. Maybe nobody will notice the first posts—or maybe the algorithms will help quickly. Everyone has something valuable to offer—show it to people.
Conclusion
Thanks for reading! I welcome critique and suggestions. Tell me what you’d like to read next. I’m still developing my writing style, so I value any feedback. In any case—thanks for your time!
P.S. I wrote this article myself. I used AI only for an accurate English translation and a few minor edits. I have a draft version to prove it. This piece was written from the heart.
And if I may, here’s a link to my app—I’d love your feedback: meum.ink
Top comments (0)