Hello World, We're JT Digital

This is the first post on the JT Digital blog, so we'll start with who we are and how we think about building software. JT Digital builds web applications for clients and makes its own tools and products.

Toni K. Turk and Jakob Raišp started the company in Slovenia in January 2026. We'll write about our tools and products in later posts. Today we want to talk about what drives the work.

How JT Digital thinks about building software

There's a version of software development where you grab the most popular framework, follow the tutorial, glue the pieces together and ship. It works, and plenty of successful products are built that way. We prefer to slow down at the start.

We want every technical decision to be deliberate. In practice that means choosing a tool because it fits the job, and keeping a solution only as complicated as the problem it solves. Shared code gets written once a pattern has actually repeated, and cleverness for its own sake never counts as a reason.

So we spend time understanding a problem before writing code, and we ask how the codebase will feel to work in six months. Type safety means our tools check every value against the shape the code expects before the program runs. We care about it because it catches real bugs before users do.

What this looks like on a national awards platform

Since December we have been building GZS Inovacije, the platform for the national innovation awards of GZS, the Chamber of Commerce and Industry of Slovenia. 2026 is the first year the awards run on it.

The platform handles the full cycle: companies submit innovations, judges score them against five weighted criteria in a regional round and then a national one, and the best projects receive Gold, Silver or Bronze recognition. It brings 13 regional chambers and dozens of judges onto one system. Last year's awards drew 245 entries, and the programme ran on spreadsheets and a lot of manual coordination.

✕ Close

The admin dashboard. One screen shows every project and judge, with switches that open and close applications and each round of judging.

✕ Close

The company portal, where a business submits its innovations and follows their progress.

✕ Close

The judging form. A judge reads the entry on the left and scores each criterion on the right, and the total updates with every change.

Pages built on the server, in TypeScript

For this project we chose server-side rendering, which means the server builds every page as finished HTML. It runs on Fastify (a web server for Node.js) and TypeScript, with HTMX, a small browser library that swaps one part of a page without a reload. We write the HTML with fluent-html, a library we built ourselves, where every component is a plain TypeScript function with full type safety. A small card component looks like this.

function ProjectCard({ name, company, category }: ProjectCardProps): View {
  return Div(
    H3(name).fontWeight("bold").textSize("lg"),
    P(company).textColor("gray-600"),
    Badge(category)
  ).padding("4").border().rounded("lg");
}

There is no separate template language to learn, and no framework code for the browser to download. Because it is plain TypeScript, the editor understands every line, so autocomplete, renaming and go-to-definition all work.

When part of a page needs to change without a full reload, such as a filtered list or a submitted score, HTMX asks the server for that piece and swaps in the HTML it sends back. The data and the rules all stay on the server, and the browser only shows what it receives.

The result is one TypeScript codebase and one deployment, with fast page loads and a model that is easy to hold in your head. A request comes in, the server queries the database, builds the HTML and sends it back.

Why we're starting this blog

We're writing because we think some of these ideas are worth sharing. A few of them: you don't always need the heaviest tools to solve a problem, type safety pays back the time it costs, server-rendered HTML is underrated, and tools you build yourself with care can do things off-the-shelf ones can't.

Future posts will cover the technical decisions behind our projects, the tools we're building and what we learn along the way. If any of this resonates, follow along.