zenioynx

[zenioynx]

project/bokbi/log-5

I’ve officially started coding the Bokbi landing page. The documentation I wrote in Google Docs before starting was one of the best preparation steps I could have taken. It’s now my main reference point for copy and structure, and having it ready meant I wasn’t stuck staring at a blank screen when working on page content.

Initial Setup and Tooling

The first stage was getting the project environment ready. That meant installing and configuring all the necessary technologies before writing a single line of UI code.

The stack I settled on for Bokbi’s frontend is Next.js with TypeScript and TailwindCSS, plus Supabase for backend-as-a-service. Since I’m still relatively new to both Next.js and TypeScript, I wanted to make this project a way to learn them in a practical setting. At work, I use React with Vite and JSX, so this is a deliberate learning curve.

Configuration steps included:

Installing Sass for styling flexibility in some components

Setting up Supabase as the database and authentication provider

Creating tables for profile, stories, and collections, plus join tables for story_tags and story_collections

Adding RLS (Row-Level Security) policies to protect user data — I still don’t fully grasp them yet, but they’re in place

Configuring Supabase storage buckets for media assets (story covers, profile pictures)

I’d heard good things about Supabase’s scalability and developer experience, so I decided to commit to it for Bokbi. Following the installation guide for Next.js from the Supabase dashboard mostly worked, but I did hit a few early errors. Reading the docs, watching a couple of setup videos, and trial-and-error got me past them.

Creating and structuring the tables was the most fun part of the setup so far — especially deciding what fields were essential for the MVP and which ones to leave for later.

Learning Next.js + TypeScript

Since I’m new to Next.js, the first week was mainly learning its conventions:

How routing works using app/ or pages/ structure

Creating layouts that persist between page navigations

Importing with aliases like @/... instead of long relative paths

Once I was comfortable, I hit a different problem: TailwindCSS Intellisense in VS Code stopped working. This turned out to be due to using Tailwind v4. I downgraded to v3.4.17 and the problem disappeared.

Installed Dependencies

Here’s what’s in the project so far:

@supabase/supabase-js — database and auth SDK

framer-motion — animations and transitions

lucide-react — icons

next — the framework itself

tailwindcss — utility-first styling

typescript — static typing

cross-env — environment variable handling across OS

sass — CSS preprocessor

eslint — linting and code quality

For now, the landing page and the main Bokbi app share the same repo. I could split them later if needed, but keeping them together makes development faster at this stage.

Workflow and Task Management

I’m tracking tasks using Notion, set up in a board view similar to Trello. I didn’t want to use Trello itself — Notion keeps everything in one place alongside the documentation.

The workflow is standard but keeps me organised:

Create a new branch from main

Commit to that branch

Push after the first commit

Open a pull request

Check the Vercel preview deployment

Test changes on phone, tablet, and laptop

Make fixes or adjustments

Squash and merge back into main

I considered adding a staging branch, but Vercel’s per-branch and per-commit previews cover that need right now.

Landing Page Progress

The landing page design is ticketed out in Notion, and I’m working through them one at a time. So far, I’ve completed:

Navbar

Hero section

About section

Quote break

That’s four of ten tickets done. Once the landing page is complete, I’ll push it live so there’s a proper place to point people when talking about Bokbi. It will also link to the “Help Shape Bokbi” Google Form, which will let me collect insights from real multi-platform readers.

Thank you for reading. More soon.

[zenioynx]

project/bokbi/log-4

It’s been a while since my last update. I had a few assignments to complete with tight deadlines, on top of my job, so I had to pause everything else for a bit.

Over the past two days, I shifted focus back to Bokbi — specifically, the documentation. I wanted to gain a clearer, deeper understanding of what this web app actually is. Not just calling it “a reading tracker,” but putting into words the structure, purpose, and scope of what I’ve been building. Writing it all down also makes it easier for others to understand Bokbi, and while doing that, I even uncovered a few UI screens I had forgotten to design.

In the middle of writing those docs, I hit a bit of a block — so I decided to move forward with actual development. I officially started coding the landing page and set up the base project for the MVP. Once the landing page is done, I’ll have something concrete to point people to when I talk about Bokbi. That also means I’ll finally be able to link the “Help Shape Bokbi” Google Form to it, which I’ve had ready for a while.

Sometimes I still wonder if anyone besides me will use Bokbi. Whether there’s even an audience for something like this. But I trust that God wouldn’t let me build all this for nothing. I know there are other readers out there like me — reading across AO3, Webtoon, random Tumblr links, and manga sites — just trying to remember what chapter they left off on. And if I can help even one person organise their reading better, then it’s worth it.

I’m not giving up. That’s what it means to be a punk rocker.

Thank you for reading. More soon.

[zenioynx]

project/bokbi/log-3

Very successful and productive day today — thank God for that. Though He might be a bit disappointed with me lately because of my behaviour, I’m still grateful for the focus and clarity I had today.

I spent the first half of the day with family, then got back to work on Bokbi in the afternoon. I was still carrying the momentum from yesterday, so I wanted to use it well.

The first thing I did was create a Google Form called “Help Shape Bokbi.” When the time is right, I’ll post it around online — looking to hear from other multi-platform readers about how they track what they read. I already know that I need something like Bokbi for myself. I like trackers. I like having my own systems. But I’m also interested in whether other people have the same struggles — forgetting where they left off, losing links, trying to track things across fanfiction sites, manga apps, and webnovel platforms.

To be honest, Bokbi started off as something just for me. But I also think keeping it only for myself would feel wrong — especially when I think about how Christianity talks about community and sharing what we create with others. If no one ends up using it, that’s fine. But I still want to try and make it available for anyone who might need it too.

Today’s design progress included three areas:

the Edit Profile page

the default new user state (what a fresh account will look like)

a simplified version of the footer

Tomorrow, after church, I want to focus on the Site Settings page and the Stats page. That’ll include user stats and reading stats tied to stories in the library.

Thank you for reading. More soon.

[zenioynx]

project/bokbi/log-2

I’ve taken a break from the Fields of Mistria project. I hit a bit of a wall with it and didn’t want to spiral into unproductive territory, so I switched focus back to Bokbi.

The last time I worked on Bokbi, I was stuck on the landing page. I remember struggling with the design for days, then eventually giving up and starting the game planner project instead. The idea of Bokbi slowly moved to the back of my mind. But when I opened it again yesterday, something clicked — and within two days I had the full landing page designed in Figma.

It’s about 90% done in terms of how happy I am with it. There are still some parts I’m unsure about, but I’d rather build it out first and let those decisions surface naturally through the process. It’s easier to fix something that exists than to perfect something that doesn’t.

Now the question is what comes next.

Most of the internal pages — the ones users will see once they’re logged in — are already mostly designed. So that’s what I’ll focus on now: finishing the remaining screens, cleaning things up, and finalising the user flows.

After that, I’ll move onto building the landing page and getting it live. The domain is already bought and I have a Hostinger subscription ready, so hosting is sorted. Once the landing page is live, I can start collecting interest or at least point people to something that explains what Bokbi is and who it’s for.

Thank you for reading. More soon.

[zenioynx]

project/game-planner/log-3

I’ve arrived back in the UK and I’m back in my own bed — which means back to coding this project properly. I’d say I’m around 70% done at this point.

Since the last update, I added the fish data to the project. That meant building out the details page for fish, and adding filtering to the fish page. I also made some small additions — more locations in the JSON file, a new fish size JSON (did I need to make this? absolutely not, but I like JSON files and will make one for anything), and fixed some navigation issues with the back buttons.

People say you don’t need to add every feature in version one — but I do. And I will. I debated whether things like the shopping/prep list or favourites should be added later, but I already know I won’t enjoy using the app without them, so they’re going in now.

I also lied about setting up the Firebase database the other day — I was too busy trying to leave a beautiful country to return to... this one (joking, I love England). I’ll probably get that done by the end of the week. I also have something called a “job,” so I’ll be doing “job tasks” during the day.

I recorded a quick video showing where the project is currently at. Next, I’ll be working on the recipes page, including the filtering and the detail view — I think this part will be fun to build.

After that: Firebase setup, plus login and signup pages for account creation.

Thank you for reading. More soon.

[zenioynx]

project/game-planner/log-2

I’ve spent the past few days in Salzburg and Hallstatt, Austria. Both have been peaceful and visually calming locations to continue this project. I would recommend the environment for working remotely or coding in general.

During the day, I’ve been out enjoying my surroundings. In the evenings, I return to the hotel and continue building the project from bed. That has been the pattern throughout this trip, and it’s been productive.

Since the last update, I’ve made several key changes to the project:

The full JSON file for all the crops is now complete. It includes essential details such as seed cost, selling price, growth time, whether the crop is forageable, and relevant locations. This dataset now powers the crop-related views throughout the app.

The UI for the crop detail page is based on a layout I found through Pinterest — my frequent resource of inspiration. The overall look of the app follows a ‘grocery shopping app’ style rather than matching the aesthetic of the game it supports. I initially considered a retro, pixel-art visual style, but didn’t pursue it due to time constraints. I chose to prioritise feature completion during the holiday window so I could use the app when I return home.

A simple calculator component has been added to the detail view. It allows the user to input quantities and receive total sell price or cost. This removes the need to switch apps mid-game to do basic calculations — something I often found myself doing manually.

On the homepage, the favourites section is now semi-functional. I’ve also added seasonal buttons that, once wired, will route the user to the Search page with filtered results based on the selected season.

Filters have been added to the “All Crops” page. The same filters have not yet been applied to the Search view, as I intend to wait until the additional datasets (Fish and Recipes) are imported. This will avoid redundant work.

As today is the last day of the trip, I’ve set two small goals for the return journey:

First, create the Firebase database for storing user data. Initially, I considered local storage, but I use multiple devices and want the data to persist between them. Cloud-based storage is the better option.

Second, begin setting up functionality for a “shopping list” feature, which will rely on that same database connection.

Thank you for reading. More soon.

[zenioynx]

project/game-planner/log-1

Last day in Munich, Germany before travelling to Salzburg, Austria. Development continues from the hotel room as I do.

Since the last update on this project, I’ve made good progress. The main task has been improving the search functionality. At the moment, it is partially working but not yet to the standard required for proper usability. The core issue was the lack of usable data — there was nothing for the search to pull from. To address this, I created a temporary JSON dataset (the data from the game's wiki) as a stand-in while developing the logic.

I moved on to designing and implementing the result cards. These are simple display components meant to show essential information about each item in the game — name, type, season, and value where applicable. The layout works, but I’m not satisfied with the visual design. Rather than spend too much time adjusting it now, I’ve decided to move forward and revisit styling after functionality is complete.

The current focus is on building out the Home page. This page will contain three sections. First, a favourites panel that shows up to ten saved items, with horizontal scrolling enabled for mobile. Second, a season selector widget — tapping a season should automatically route to the Search page and display all related items, regardless of category. Third, a recently searched panel for quick reference, which is a precaution for forgetful use-cases.

Thank you for reading. More soon.

[zenioynx]

project/game-planner/init

I’m currently in Munich, Germany on holiday.

And what better way to relax than coding a new project from my hotel bed, while German TV hums quietly in the background. This is my idea of a break — quiet, slow, and productive in a way that feels optional.

The project started, as usual, from a problem I keep having. I play a farming sim, and every time I return to the game, I find myself searching the same wiki pages for the same information: crop prices, fish locations, recipe ingredients. I only ever need a few key details — maybe 3 to 5 lines — but the wiki is dense. It’s not built for speed, or clarity. It’s built to hold everything.

And I don’t want everything. I want just enough to keep playing without pausing too long.

This feels similar to my usual habit of forgetting how to start coding projects — which is what led me to make my own quick-start guides. This time, it’s the game equivalent: a tool to pull only the useful bits I actually care about, in a format that works for me.

So, I’m building a PWA.

After experimenting with a small test PWA the other day, I now understand how to make a site installable and usable offline. It makes sense to combine that with this use case — I want this app on my phone or iPad, the devices I actually use while playing. Something quick to open, simple to search, and still accessible even when Wi-Fi is bad or unavailable.

Right now, I’m working on the mobile layout. In the header image, I’m working through the Home and Search views. It’s early, but the concept is working — and if it saves me even five wiki clicks a day, it’s worth it.

Thank you for reading. More soon.

[zenioynx]

blog/first-pwa-test

Recently, in my spare time, I’ve found myself drawn to yet another project idea — something new I’m curious about and excited to explore.

I’ve been feeling a bit stuck with my three main projects. Progress has slowed, and instead of forcing it, I’ve shifted focus — again — to something different. This time: Progressive Web Apps (PWA).

The concept is simple enough: by adjusting the structure of a standard web app, you can make it behave more like a native app. PWAs can be installed directly onto your phone or tablet, and in many cases, they’ll still work offline. I’ve seen this behaviour in real life — certain sites prompt to “install” themselves, and I always wondered how that worked.

So I tried it.

I built a small test site, deployed it to Netlify, and then visited the site on my phone. It prompted me to add it to my home screen — and it worked. I turned off Wi-Fi, reopened it, and the site still rendered. That was the confirmation I needed.

Now that I’ve seen the flow work end-to-end, I want to apply this to a real project — one I’d genuinely like to use offline. Realistically, the project would work best as a native mobile or tablet app. But I don’t have the skills for that yet, and the PWA approach is the closest I can get for now.

Hopefully, I’ll begin proper work on it today.

[zenioynx]

projects/reference-page/init

Lately, I’ve noticed I keep running into the same problem: I forget how to start things.

No matter how long I’ve been coding, I still find myself going back to documentation just to remember how to properly initialise a project — whether it’s React, Vue 3, or something more niche like browser extensions.

The short-term solution I’ve been using is Google Docs. I’ve made separate guides for each tech stack I use regularly — just the basics, like setup steps and file structure. I wanted something I could access anywhere, so I ruled out local files. Docs was simple and reliable.

But now I want to take it a bit further.

The idea is to create a simple website that acts as my own reference portal — all my startup guides, formatted the way I like, with a layout I control. It’ll be another small programming project, but not one I mind doing.

I’ve considered alternatives. GitHub Gists felt too clunky. A repo with README files could work, but I prefer more flexibility in how it looks. A CLI tool might be interesting someday, but not now. For the moment, a custom site feels right.

Another project added to the list — alongside the ones I came up with last night and this morning.

Thank you for reading. More soon.

[zenioynx]

projects/making-apis/log-1

I started the project around 10:30am.

The first API I wanted to build was something static — minimal, requiring little to no updates. I decided on an API that holds a collection of all 37 miracles performed by Jesus Christ during his life on Earth, based on the accounts in the Bible. It felt like a good, contained dataset to begin with.

This was also my first time properly using Express.js. I don’t fully understand it yet — but I’m learning by doing. I structured the project with an app.js file, a separate JSON file for the data, and a routes.js file for handling the endpoints.

After some refactoring and inserting the full list of miracles into the JSON file, the next challenge was deployment. I Googled around and found Render.com, which allows you to deploy a live API for free. I also came across RapidAPI, where developers can list their APIs as products — but for now, I just want it working. Not monetised.

After some trial and error, it’s live on Render. The data loads, the endpoint works, and I can fetch it. It’s simple, but it works. That was the goal. I finished today's task at 3:15pm.

I haven’t listed it on RapidAPI yet. I’d like to design and upload a small landing site for it first — that part, the UI, is what I enjoy most. I also want to test it inside a separate project, fetching from the live version instead of localhost.

But that’s tomorrow’s task.

Thank you for reading. More soon.

[zenioynx]

projects/making-apis/init

One of the weaker points in my skillset has always been creating APIs.

In my day-to-day work, I rarely need to write them from scratch. Most of the time, other team members handle the API side — creating endpoints, managing requests, integrating services. I’ve mostly avoided it. For a while, I wasn’t sure why.

Eventually I realised it was because I didn’t fully understand them. I knew how to use APIs. I didn’t really know how to build them. And that gap quietly stayed there, unaddressed.

So I’m going to try filling it.

The plan: create five APIs from scratch over the next two months. Small ones.

I’ve seen people build and ship APIs in a weekend, publish them to marketplaces like Rapid. Others take weeks or months to polish something more complex. I’m not aiming for anything massive — I just want to build a few clean, functional ones end-to-end.

That’s the goal.

Thank you for reading. More soon.

[zenioynx]

blog/developer-vs-engineer

I don’t love Software Engineering.

I trained as a Software Developer. That’s what I enjoyed then, and it’s still what I enjoy now. My previous role was Web Developer. I liked it. My current title is Software Engineer — and I don’t enjoy the “engineering” part.

I don’t aspire to architect systems. I’m not aiming for infrastructure mastery or microservice design. I like building things and then moving on. My brain works in tasks. In quests. A feature is a problem; I solve it and move forward. That’s the rhythm I understand.

When the conversation shifts to CI/CD pipelines, scalability, deployment pipelines, I disconnect. It’s not just disinterest. There’s an expectation in tech that every developer should eventually care about “the bigger picture.” But not everyone wants to be two roles in one.

I prefer tickets that ask for new components, new features, fixes with visible outcomes. That’s where I focus. That’s what feels good. I see other engineers talk deeply about pipelines and system stability — and I respect it — but it’s not for me.

What I enjoy is turning design into reality. From idea → interface → interaction. That’s the role I want.

And that’s why I prefer being and being called a 'Software Developer'.

[zenioynx]

project/bokbi/log-1

One part of building Bokbi that I’ve been avoiding — or at least delaying — is the landing page.

Whenever I begin a new project, I tend to focus on the internal experience: the parts that matter once the user is already inside. Logged in. Actively using the thing. That’s where I naturally gravitate. The dashboard. The form flows. The tagging systems. That part makes sense to me.

But the landing page is different. It has to explain. It has to invite. It’s for people who haven’t used the app yet — who don’t already understand the problem it’s solving. That shift in mindset has always been more difficult for me.

The issue isn’t really the wording. I know what Bokbi is, and I can describe it. What’s more challenging is the design — how to build a landing page that suits the nature of this project. Something niche, fandom-adjacent, personal — but still clear, clean, and easy to understand.

The image above is an early mockup of the landing page. It’s not even close to the final design — honestly, I find it a bit ugly. But for now, it serves its purpose: explaining what the app is and who it’s for.

At the moment, I’m drawing inspiration from Vercel’s “v0” and collecting visual references on Pinterest. I’m not just looking at aesthetic direction, but also page structure and content hierarchy.

I’m turning my focus to that page. My goal is to complete a first proper version of the landing by the end of the week. Even something minimal — just a space to introduce Bokbi, outline its purpose, and set the tone.

It doesn’t need to be final. It just needs to exist.

Thanks for reading. More soon.

[zenioynx]

project/bokbi/init

Bokbi is a web app I’m building — a reading tracker for multi-source, non-standard content. It’s meant for people like me who read across fanfiction sites, manga aggregators, webtoons, and random webnovels, and have no centralized way to track any of it.

I started this project for personal use. I’ve tried using spreadsheets, Notion templates, even dedicated apps — but nothing really worked. Most of them are too rigid, or only support one kind of content. I wanted something that let me track everything I read, no matter where it came from. So I began designing my own.

I have bought a domain for it and right now, I’m working in Figma — building out the main screens of the app: → A library/dashboard → The “Add a Story” flow → Story detail pages (with tags, notes, reading status)

I’m holding off on coding until the core UX feels solid. I want to know how I want it to function before I worry about implementation. I’m also spending time doing research — looking at how other people manage their reading across platforms, and what features are actually useful in practice.

This is the first time I’m developing something that feels like it could be useful beyond just me. Which is exciting and weird. I'm primarily a frontend dev, so the backend side of things will be a stretch — but I want to learn.

Bokbi is my main focus at the moment. I’ll be documenting its progress here.

Thanks for reading. More soon.

[zenioynx]

✶ This is a Coding blog

I am a Software Developer. I program websites / web apps 99.9% of the time. I do have various projects going on at the same time. This is a place where I talk about them freely.

✟ Expect:

programming logs (front-end focused)

design ideas + iterations

project updates

No fixed schedule. Just progress.