Articles — .NET, Nuxt, Telegram Bots and AI in Practice

Part 26 of the series about building a Telegram task tracker in a tiny team. How Boards got AI that turns a stream of thoughts from a chat into a neat task: DeepSeek in production, Ollama for local development, our own OpenAI-compatible client on HttpClient and the /aisave command in Telegram.

Part 25 of the series about building a Telegram task tracker in a tiny team. How the Boards bot learned to work in group chats: linking a chat to a board with /link, two message save modes, the admin check, privacy mode and a group turning into a supergroup.

Part 24 of the series about building a Telegram task tracker in a tiny team. How the web app token moved from localStorage to an HttpOnly cookie: how ASP.NET Core reads a JWT from a cookie, what the Nuxt frontend needed for it, how to set up CORS, and how we made the project easier to run locally.

Part 23 of the series about building a Telegram task tracker in a tiny team. Why the Boards UI had to be rewritten, how the new frontend architecture works with every page declaring its dependencies explicitly, how that helps Vitest tests, and why the repository has a file of rules for AI agents.

Part 22 of the series about building a Telegram task tracker in a tiny team. How task comments work in Boards: who can read, write and edit them, why they load in a separate background request, and how pagination works without a COUNT query.

Part 21 of the series about building a Telegram task tracker in a tiny team. How we let the web app upload images to tasks and store them in Telegram through a bot and brought files from the bot and from the web under one attachment model.

Part 20 of the series about building a Telegram task tracker in a tiny team. How Boards got a change history for tasks, why we write it explicitly in services in the same transaction as the changes themselves, and why EF Core interceptors, temporal tables and event sourcing did not fit.

Part 19 of the series about building a Telegram task tracker in a tiny team. How we added attributes (custom fields) to issues, why we chose an EAV model with a separate value table per type instead of a JSONB column, and how filtering tasks by attribute values works.

Part 18 of the series about building a Telegram task tracker in a tiny team. How issues got sequential numbers like BRD-42, why a counter on INSERT ... ON CONFLICT DO UPDATE suited them better than a PostgreSQL sequence, and how space keys and organization URLs work.

Part 17 of the series about building a Telegram task tracker in a tiny team. Why Boards has no roles, how the permission system went through four versions looking for a balance between flexibility and simplicity, and why permissions are now granted only on the organization and the space.

Part 16 of the series about building a Telegram task tracker in a tiny team. How we added organizations to Boards: a shared-database data model, a personal organization for every user, joining by an invite code, and a separate JWT issued when a user enters an organization.

Part 15 of the series about building a Telegram task tracker in a tiny team. Why we wrote our first integration tests when the app was already in production, how the test host on WebApplicationFactory with a real database works, and our own proxy that turns a controller method call into an HTTP request.

Part 14 of the series about building a Telegram task tracker in a tiny team. How spaces group boards by project, why the space lives on the board and not on the issue, and the SQL migration that gave every existing user a default space.

Why we deleted our own markdown-to-API backend and moved the blog into the Nuxt app — the frontend/backend sync problem, the things the system did not support, and what got simpler after the move.

Part 27 of the series about building a Telegram task tracker in a tiny team. We built an MCP server for Laraue Boards to understand how MCP works, then started using it with Claude Code every day. How the first version came together in two hours, what was wrong with it, and the daily loop it made possible.

The modern approach to development increasingly comes down to one claim — AI should write the code, and the developer just steers it and checks the results. The fact that reviewing generated code well enough to trust it is often slower than writing it yourself gets quietly left out.