How I built a fully-fledged site by Myself

Adam Henderix
4 min readJan 13, 2024

I built a site for sharing recipes in three months called Favedis.com and here is a general outline how I built it.

Technical Overview

The overall structure is based on a backend server serving API calls and appending new data to the database built using Django as well as a front-end framework that is Svelte.

My backend server in detail is Django with DRF, Oauth for Google sign-in, postgres for database hosted on Railway, S3 bucket for storing user-specific data and fly.io for hosting the server.

I also had to install CORS in order to get my backend-server to accept incoming requests from the front-end server, which normally is disabled for security reasons.

Remember that you should always look as the relationship between a frontend and backendserver as a 1-way relationship, where the user is asking the backend to do something. I see far too often people allowing too much power to the user, which can lead to vulnerabilities. You have to check if it’s a valid user, check if they have the given karma/points/reputation to pursue the action and validate the data they might send. You want to give the user a tiny little box to work with and nothing more, this is how you stay secure from most hacks.

It’s important to note that Django comes with a lot of built-in protection so you don’t really have to think about that much on your own. It’s mostly business logic that can go wrong if you don’t know what you’re doing.

Backend services and technologies

My reason for having multiple providers was due to the fact that every one of these serviecs did one thing well. Fly was great because it’s essentially a 1-click upload experience once you’ve downloaded the related things and gotten setup.

I use AWS for the S3 bucket because it’s the only provider aside from Azure that I could find offering extensively offering this.

I also used minor libaries for setting up the server such as gunicorn and whitenoise for serving static files so that my admin panel actually worked on the server.

For the database I used Postgres with Railway. It was a very seamless experience and I wouldn’t want to use anything else. In the future I might migrate from fly.io to Railway with my server as well, because Railway is an industry-standard for Django developers, although it takes a bit more setting up.

My overall view on a backend server is that it should be doing minimally amounts of computation, because as your userbase grows, the burden of doing inefficient computations grow exponentially. Therefore I suggest implementing caching, which essentially means you store a certain state of the front-end and then serve those pre-built sites to the user.

Frontend technologies

The frontend technologies are a lot simpler. I used Svelte (Not Sveltekit) as the basis for everything. Along with it I highly suggest Vite to help you with the installing, and also implementing Vercel analytics. Vercel analytics has a pretty greedy business model, but it can serve as an important tool with the free stats you gain, to help you find signals as to why people leave.

For my case I realized people visited the index page and often left, making me realize my messaging was poor. I wouldn’t have realized this if I didn’t have analytics available.

Coincidentally I also host the front-end server on Vercel due to their free hosting and easy of implementation. All you need is to uppload your code to Github, connect to vercel and publicize your project via their interface.

For domain I just used porkbun. I don’t think it matters too much which one you choose, but due to the spam you get when you look for a decent provider, it becomes hard to find the right one. Namecheap is also okay in my experience.

I initially built the front-end, because I wanted to put my idea into fruition on a real page. Once I had a basic interface to work with, I’d start applying post requests to all the buttons, hook them up with a corresponding API on the back-end and pursue with it.

Key takeaways

My biggest regret was not picking Sveltekit for the frontend. I would have gotten more done, had a faster site with server-side rendering, cleaner routing, built-in SEO support and many more useful features. I would highly suggest using it over just Svelte. I used Svelte just because I was told it was better for SPA-rendering, but it’s not really worth drooling over, especially considering Google still favors traditionally rendered pages.

I would also have stuck with Railway for my server. Currently my database is hosted on Railway, but my server on fly.io which works fine, but it feels weird to have things spread out. Fly is amazing for deployment, but it sucks for databases. Last time I tried migrating it wouldn’t deploy on Railway, and I haven’t tried again since, which is a bad idea, but then again my site is just an MVP to test a concept.

If I ever get users I intend to use Stripe for potential payments. It’s truly the best out there. Don’t even considering using anything else.

--

--

Adam Henderix

I write about AI-related topics and publish on the weekends. I’m interested in empowering people towards having an impact as the optimal way of getting there.