What I Learned Building Inkora

I started building Inkora as a blog platform. Somewhere along the way, it became much more than that.

When I first decided to work on Inkora, my goal was straightforward: build a platform where people could write, publish, and share ideas.

But as development progressed, I kept asking myself:

«“What would make this more useful than just another blogging platform?”»

That question changed the direction of the project.

Inkora gradually evolved into a platform with writing, social interaction, profiles, notifications, flashcards, and private messaging. And with every feature came a new lesson.

The Difference Between Designing a Feature and Actually Building It

Creating a beautiful interface is one thing.

Making that interface work reliably with authentication, databases, APIs, state management, security, and different devices is another.

Building Inkora helped me understand that a feature isn't really finished when it looks good.

It is finished when it works, handles unexpected situations, and provides a good experience for the person using it.

For example, authentication started as a relatively simple requirement. But it eventually involved registration, login, session persistence, email verification, username generation, validation, and handling different authentication states.

That was a reminder that the visible part of a feature is often only a small part of the actual engineering work.

One of My Biggest Challenges: Messaging

One feature I'm particularly proud of is Inkora's private messaging system.

I wanted messages to be genuinely private, so I implemented end-to-end encryption using the Web Crypto API.

Instead of sending readable messages to the server, messages are encrypted in the user's browser before being stored.

That meant dealing with concepts such as:

• ECDH key exchange
• AES-GCM encryption
• Persistent key pairs
• Nonces
• Public and private keys
• Client-side encryption and decryption

I didn't just want to add a “secure” label to the feature.

I wanted to understand what was happening underneath it.

That experience pushed me to think beyond simply making something work and start thinking about how it works and why it works that way.

Then Came the Problems I Didn't Plan For

Some of my biggest lessons didn't come from successfully implementing features.

They came from things breaking.

Database migrations went wrong.

Authentication produced unexpected errors.

Production environments behaved differently from my local machine.

Deployment exposed configuration problems that weren't obvious during development.

I had to learn to stop looking at an error message as just a problem and start treating it as information about what the system is actually doing.

An error like "P1001", "P1010", or a platform-specific build failure isn't just noise.

It gives you a direction to investigate.

AI Helped, But It Didn't Replace the Developer

Inkora also changed how I approach AI-assisted development.

I've learned that giving an AI agent a vague instruction and expecting a perfect application isn't enough.

You need to know:

• What should it build?
• What should it not change?
• What constraints should it follow?
• How will I know the implementation is correct?

The better I became at defining those things, the better the results became.

AI can help accelerate development, but you still need to understand the product, review the implementation, test the result, and make the important decisions.

That distinction has become one of my biggest takeaways from this project.

Inkora Is Still a Work in Progress

Even after deploying Inkora, I don't consider it finished.

There are still features I want to improve, infrastructure decisions to revisit, performance to optimize, and new ideas I want to explore.

And honestly, that's one of the things I enjoy about building software.

There is always another problem to solve.

There is always another version to build.

There is always something you can make better.

Inkora started as a project I wanted to build.

Now, it has become a practical learning ground for me as a developer and founder.

I'm learning not only how to write code, but how to think about products, users, security, infrastructure, debugging, deployment, and the decisions that turn an idea into something people can actually use.

«The code is important. But the person you become while building it is even more important.»

And I'm just getting started with Inkora.