DEV Community: Byteminds Agency

Starting as a Professional Frontend Developer

Byteminds Agency — Fri, 06 Mar 2026 11:21:35 +0000

Hey! I'm a frontend developer at ByteMinds. It's been six months since I joined the team and first encountered real production code.

Before this, my experience consisted of pet projects and courses where everything was usually "sterile." In this article, I want to share not just impressions, but real experience of "surviving" in a commercial project. This is an honest story of what to be prepared for if you're looking for your first job.

The Stack: Expectation vs Reality

When I was studying, I thought projects picked one modern framework (like React) and everything was strictly built with it. In the "ideal world" of tutorials, that's exactly how it works.

Reality: In commercial development, it's different. Right now I'm working on projects managed by CMS platforms (Umbraco and Optimizely). These systems are built on .NET, where most of the frontend is rendered server-side through Razor templates (CSHTML).

In this architecture, React isn't the "king" of the entire project. It's used selectively - as isolated components or blocks with complex logic that get embedded directly into Razor templates. The result is that on a single page, you might have several isolated React applications coexisting alongside markup that uses plain JavaScript scripts where needed. It turns out the ability to quickly switch between a framework's declarative approach and imperative vanilla JS is a crucial skill for "real combat."

Typical project situation: a page renders through Razor, you're tweaking card markup and adding simple logic with vanilla JS, and on the same screen there's an isolated React component handling something complex - filtering, state management, async requests. Within a single task, you constantly have to switch between these approaches and choose the right tool for the specific problem, rather than trying to force everything into React for the sake of "architectural purity."

The Codebase: Not "Bad Code" but a History of Decisions

A junior's first shock is legacy code. At first, it seems like the people who wrote this never heard of design patterns. But over time, understanding dawns: the codebase is a history. Some decisions were made in a rush before a release, others were driven by specific client requirements that changed three years ago.

Navigating these layers of different eras is an art in itself. That's where modern tools and colleagues come in handy.

AI as a Co-pilot: My Experience with Cursor

For me, Cursor has become an indispensable accelerator. I use it for pragmatic tasks where it's more efficient than manual searching:

Context and navigation: It's great for understanding which files contain scattered logic and how components relate to each other in a massive project.
Routine and boilerplate: Generating TypeScript types for an API or scaffolding a component structure - tasks that AI handles like a pro.
Risk assessment: Before refactoring, you can ask: "Where is THIS used, and what will break if I delete or change it?"

Writing complex business logic? I wouldn't trust it with that yet, to be honest. AI is like an intern who works really fast but can confidently spout nonsense. So you still have to check every line of code.

Colleagues

Asking colleagues questions is one of the fastest ways to figure out a task. They often have context that isn't in the code: why a particular solution was chosen, what was tried before, and where the hidden pitfalls are.

These discussions not only save time but also help develop your "gut feeling." Gradually, you start to understand better where the real risks are and where you need to dig deeper, versus where you can accept the existing solution and move on.

In commercial development, this is critical: it's not just about writing code, but doing it safely for the project. Talking with colleagues accelerates your onboarding and helps you start thinking in the context of the product, not just an individual task.

Design and Communication

In pet projects, you're your own client. In commercial work, mockups are the foundation, but life throws curveballs. For example, a mockup shows 3 tags on a card, but the backend sends 7, and suddenly your layout starts to "dance."

It's important to understand that design isn't always the ultimate truth. Often, designers themselves see their work more as an aesthetic direction rather than a strict final result. They don't always know 100% what real content and in what quantities will come from the backend.

At that moment, responsibility falls on the developers. We're the ones who see the real data and have to decide how to display it as closely to the design as possible without breaking the UX. If in doubt, it's best to go to the designer and clarify their intent. But over time, you develop a feel for the boundaries of flexibility: where you can adapt the solution yourself, and where sign-off is crucial.

This approach teaches you to be more than just "hands" - it teaches you to be an engineer who thinks about the user and the product, and tries to solve a problem before it surfaces in production.

Sometimes You Have to Make Trade-offs

Things Don't Always Go to Plan: The Carousel Case

One of the most memorable moments was a task to implement a block that was a hybrid of a marquee and a regular slider. The designer kindly provided mockups with animation, approved by the client.

The requirements:

Two rows of slides moving in the same direction, but at different speeds.
Continuous movement (like a news ticker, linear flow), not slide-by-slide.
Looped movement.
Overall controls: autoplay on/off, next/previous slide.
Slides are clickable cards.

The Technical Struggle

Initially, the project already used the Swiper library and had dozens of sliders implemented with it, so I decided not to add new dependencies. But, as it turned out, standard Swiper is designed for flipping through slides, not for linear flow (surprising, right?). To "squeeze" it to meet our needs, I had to search for hacks.

I found a configuration that turns the slider into a marquee:

typescript
const swiperDefaultOptions: SwiperOptions = {
  modules: [Autoplay, FreeMode],
  autoplay: {
    delay: 0,
  },
  freeMode: {
    enabled: true,
    momentum: false,
    momentumBounce: false,
  },
  loop: true,
  slidesPerView: "auto",
  spaceBetween: 24,
  speed: 4000,
};

// Initialization
this.swiperTopCarousel = new Swiper(this.refs.topSwiper, {
  ...swiperDefaultOptions,
  speed: Number(this.refs.topSwiper.dataset.speed) || swiperDefaultOptions.speed,
});

And of course, a bit of CSS magic was needed. For smooth scrolling and predictable behaviour:

css
.swiper-wrapper { transition-timing-function: linear; }

Seemed to work fine, the hack solved everything, but...

Janky loop when dragging. This became the main pain point. Because the slides had different widths, Swiper didn't calculate the "seam" point of cloned slides correctly. Visually, it looked like a jerk: the container would suddenly jump back to loop the animation. A possible fix would have been to calculate slidesPerView precisely, but for the sake of responsiveness, we needed the auto value. The solution: we had to take away the user's ability to drag the slider. Harsh? Yes, but navigation buttons were still available.
Stop on click. Clicking a slide would stop Swiper's autoplay. I never fully figured out why. People online who'd implemented this hack suggested disableOnInteraction: false and pointer-events: none on the container. But that didn't work for us – the cards needed to be clickable.

The Solution: Compromise and a Second Library

I realised I was trying to force Swiper to do something it wasn't designed for. The ideal candidate seemed to be Splide. It has a built-in type: 'loop' mode with proper slide cloning, which solves the jerking issue. And the AutoScroll module smoothly moves the entire strip:

typescript
const baseOptions = {
  type: 'loop',
  autoWidth: true,
  gap: gap,
  arrows: false,
  pagination: false,
  drag: false, // disable drag, rely on autoscroll
  clones: clones
};

this.topSlider = new Splide(this.refs.topSlider, {
  ...baseOptions,
  autoScroll: {
    speed: 0.4,
    pauseOnHover: false,
    pauseOnFocus: false
  }
});

this.topSlider.mount({ AutoScroll });

Now came the dilemma: the project already had dozens of carousels using Swiper. Rewriting them all would be unjustifiably time-consuming and risky. Leaving the Swiper hack meant not delivering the task with the required quality.

In the end, I made the tough call: to add Splide as a second library specifically for this case. Yes, it increases the bundle size. But in this situation, it was the only way to achieve truly smooth animation without writing a custom solution from scratch.

When making such decisions, it's important to base them not just on code "beauty" and universality, but on the component's importance to the product. This carousel was the main visual feature of the case studies page and grabbed attention on first visit. Since the component directly impacted the first impression of the design, we decided not to compromise on the visuals.

Lesson learned: sometimes it's better to sacrifice bundle size for a solid UX and a stable solution, rather than maintaining fragile hacks in a critically important part of the interface.

On Estimates and Responsibility

Estimating tasks is pretty stressful at first. You allocate a certain amount of time, and you work towards it, but one unexpected carousel can eat up a good chunk of it due to unforeseen technical nuances.

This taught me that an estimate isn't just a number the project should be ready for. It's always about planning for risks, even when it seems like there couldn't possibly be any. Now I always try to build in a buffer for researching existing code and unexpected circumstances.

Conclusion

Over these six months, I've understood the main thing: commercial frontend isn't just about writing code in the latest React. It's about the ability to work with what's already there, to negotiate, and to find a balance between "beautiful code" and a working business. It's harder than it seems in courses, but also more interesting and varied. In the end, I'd highlight these key takeaways:

Proactivity matters more than knowledge: If a task isn't clear - ask. It saves hours of wandering.
Ideal code is sometimes the enemy of the product: In reality, you sometimes need to compromise to get a feature working stably and on time.
Respect for Legacy: Instead of criticising "crappy" code, focus on improving it safely.
Soft skills are key: Being able to explain your thoughts and accept feedback in code reviews makes you grow faster than just memorising syntax.

These were just the first six months. Real production is a noisy, non-linear thing, and school doesn't prepare you for it. But it's precisely in this chaos that you build the skills that make you a real developer.

Author: Yakov Shevcov, Frontend developer, ByteMinds

Speeding Up Layout from Figma with MCP and Cursor

Byteminds Agency — Fri, 13 Feb 2026 11:23:40 +0000

Converting a design from Figma into code is an unavoidable stage of development, one that's often tedious and time-consuming. Even when we work with design systems where colors, fonts, and spacing are standardized, and layers and components are neatly named, transferring styles and double-checking every detail still eats up a lot of time and energy.

If you're still stuck in the copy-paste loop and are thoroughly tired of this routine - it's high time to look towards AI and the useful tools it can offer. In this article, I'll show you how to leverage the full power of AI assistants in the design implementation process, using the duo of Cursor IDE and an MCP Server as an example.

MCP (Model Context Protocol) is a tool that burst onto the scene in 2025 and quickly found its place in the AI tool ecosystem. Its emergence was a logical step in the evolution of AI agents, which outgrew the limited context of a single model.
MCP is an open-source standard that describes how AI agents and applications interact with each other and with external systems. Simply put, MCP acts as a language interpreter between products and Large Language Models (LLMs). It receives data in a specific service's "language" and translates it into a format the AI can understand.
In other words, MCP allows AI agents to expand their capabilities by gaining access to a broader context. Through MCP, an AI can safely fetch data via API, search for information, perform analytics based on external services, and complete other tasks beyond the base model's reach.
Companies like Figma can create their own MCP servers for their products by implementing this standard. Such a server knows how to call the product's API, extract the necessary context, and pass it to the agent in a structured way. In Figma's case, an MCP server directly integrates Figma into the workflow, providing AI agents with design information and the context needed to generate code based on Figma design files.

Requirements

Integrating such a tool into your workflow isn't complicated. You'll need: a code editor with MCP support (VS Code, Cursor, Claude Code, Codex, etc.) and access to a Figma project.

Of course, there are nuances, such as design requirements, Figma's pricing plan, and other details. We'll discuss those a bit later.

What the Process Looks Like from a User's Perspective

In broad strokes, the workflow is like this:

Setting up an MCP server inside your editor.
Connecting to Figma via automatic browser authorization or manually using an access token (depending on the chosen MCP).
Prompting the AI agent to implement the layout for the desired component.
Reviewing the result, making edits, correcting the code.
Clarifying requirements and expanding the context.
Getting the result (rapid layout).

I've tried different MCPs in practice; they are all functional options with their own quirks:

MCP Cursor Talk To Figma - a bit more demanding to set up (you need to set up a local server following the instructions and run the "Cursor Talk To Figma" plugin in Figma; works even without Dev Mode access).
Framelink MCP for Figma - convenient to set up, works even without Dev Mode access.
Figma MCP Server - official from Figma (but there's a nuance regarding Dev Mode).

Let's take a closer look at the process using the official Figma MCP Server as an example.

The Process

First, log into Figma and open your design project.
Then, follow the installation instructions for the server in your IDE settings. It's genuinely simple and quick, taking just a couple of minutes. After installation and OAuth authorization, the server will show as 'enabled'.

Now the editor (in my case is Cursor) has access to a ready MCP server.
Select the desired component in the design and copy its link:

Write your prompt. It can be concise:

"Implement the component design from https://www.figma.com/design/"

Or more detailed (this makes the agent's job easier and reduces the number of operations):

"@feature.tsx Implement the component design from https://www.figma.com/design/ according to the @always.md. Use Tailwind for layout, spacing and typography. Do not download images. Use placeholders from @images"

Executing such a prompt is quite fast - from 20 seconds for small components (card, quote, hero block) to a couple of minutes for an entire page.

After that, the foundation is ready:

"- Replace custom Tailwind values with standard utility classes. For example, avoid arbitrary values like p-[40px] or text-[64px]; use default Tailwind spacing and font sizes (p-10, text-4xl, etc.) instead.- Replace custom CSS variable references in class names with design-system aliases. For example, text-[var(--color-text-light-gray)] should be written as text-light-gray."

Depending on the AI model and the complexity of the design and the existing codebase, the AI can produce different results. So, you need to help the agent with context. This is where rules come in - you can create and expand them as you see fit. The documentation offers some tips on this.

The rules I used for a project with a React+Tailwind stack look like this:

# Cursor Project Rules & Guidelines
## Always Rules
## HTML / Accessibility (Component-Level Default)
- Use semantic tags (`section`, `article`, `nav`, `header`, `footer`) where relevant.  
- Follow proper heading hierarchy inside components (don’t start with `<h1>` unless it’s a full page).  
- Every image must have an `alt` attribute.  
- Make interactive elements (buttons, links, menus) keyboard accessible.  
## Code Generation & Architecture (JS/TS + React)
- Use **TypeScript** in strict mode; avoid `any`.  
- Prefer **type** over `interface` (except for classes).  
- Use **named exports only**; avoid default exports.  
- Prefer **guard expressions** instead of nested conditions.  
- Use **union types** instead of enums; `as const` objects are allowed.  
## CSS / Styling (General)
- Use Tailwind for styling.
- Use a **mobile-first** approach.  
- Prefer flexible dimensions (`min/max-width`) over fixed ones
## Color & Design System
- Extract exact colors from Figma data; do not approximate.
- If brand colors or repeated colors appear for the first time, create CSS variables in src/index.css.
- Use exact hex or rgba values from Figma; do not approximate with Tailwind.
- Font families and other constants should be defined in src/index.css.
- Use Tailwind responsive breakpoints for layout.
## Images and icons
- Do not attempt to download images, use a placeholder from `src/assets/images/`.  
- Always specify `alt`, `width`, and `height` attributes.  
- Use descriptive `alt` text based on the component’s purpose or content.  
## Development Workflow Optimization
- **Avoid redundant checks** - Don't check linter, existing configurations, or dependencies unless specifically requested
- **Skip obvious validations** - If package.json shows dependencies are installed, don't verify setup
- **Minimal todo lists** - Only create todos for complex multi-step tasks (3+ distinct steps)
- **Focus on core task** - Complete the main objective first, then add refinements if needed
- **Assume working environment** - Don't verify basic project setup unless errors occur

It's convenient to place the rules in a separate directory. For example, create a .cursor folder in the project root and put all rules inside a rules folder within it. Be sure to give the AI agent a link to the rules.
Here's also an example of a detailed set of rules from another project configured with Framelink MCP:

It's important to understand that the agent may selectively ignore formal rules. Sometimes, it makes sense to duplicate important requirements directly in the prompt. It doesn't hurt to add a reminder at the beginning of the dialogue like: "Respect all rules from .cursor/rules".

Another topic is the AI agent's analysis of existing styles and components. Even if the agent correctly navigates the project structure and understands current UI patterns, it doesn't guarantee the generated code will fully meet your requirements and expectations.

Here's a list of what positively affects the quality of the AI agent's output:

If you're creating a project from scratch - set up the basic CSS settings for html, body, variables, media breakpoints, fonts, mixins, etc., yourself. On this foundation, the AI can help you pull missing colors, fonts, sizes, spacing from Figma into the project, and form styles for basic UI components, placing what you need into variables.
Reference existing project files as a guide for structure, patterns, and code styles in TS/JS.
Rules should be concise, clear, and consistent.

The fuller the context available to the AI agent, the more organically the design integration into code will proceed. Context includes not only rules and component examples but also basic project settings, existing files, styles, patterns, and any documentation that helps the agent correctly navigate the structure and development approaches.

You can expand the context not only with rules and component examples. I highly recommend checking out Figma's Code Connect feature. It's only available for Organization and Enterprise plans, but it links real components from your repository with components in Figma - this way, the agent sees not only the design structure but also the actual code, import paths, props, and usage examples. If the Figma project is a true design system, such a tool seems like a must-have for a team planning to use MCP.

I also want to mention the topic of responsive design separately. AI handles generating the necessary layout based on provided responsive designs quite well. Example prompt:

"_@feature.tsx Implement the component design from Figma:

Mobile: https://www.figma.com/design/
Desktop: https://www.figma.com/design/ Ensure responsive design: switch to desktop layout at 1024px width._"

Here are a couple of visual examples for a project with only the most minimal basic settings so far, and a UI component base still being formed:
Example of a website card:

And here's an entire page:

As you can see, AI + MCP handle such tasks as well: it took me about a minute to formulate the request and generate the code. We got a result even with a raw, unconfigured project. However, this is more of a theoretical example. In practical development, this approach isn't justified. Converting an entire page at once creates an extra intermediary layer - code that will inevitably need to be redesigned, parsing and rethinking a large volume of already generated markup.

Nuances and Limitations

1. Tokens

You'll notice that executing requests consumes tokens, using up your editor's pricing plan limit. You can't avoid spending tokens altogether. But you can observe the dialogue with the AI to see what extra steps it's taking and then experiment with different models. For example, you can skip linter checks and intermediate code reports in the rules, etc.

Real examples:
Implementing a card component: 161.9k tokens – $0.10
Implementing a home page (6 sections): 433.6k tokens – $0.21

2. Figma API Limits

After a couple of hours of work on a free plan, you'll likely get a "429 – too many requests" system message. This is a Figma API limitation, not MCP. As explained on Figma's site, this happens because applications and integrations are only allowed to send a certain number of requests to the REST API on your behalf. The limit depends on your pricing plan, license, and file location.

In other words, using MCP on Figma's free plan will only work sporadically, a little, in test mode. Full-fledged work requires access to a paid plan.

3. Dev Mode

For the official Figma MCP, you need Dev Mode - a paid feature. Their site says the remote server is available for all seats and plans, and the desktop server is available for Dev or Full seat on all paid plans. In practice, I only managed to connect to the remote MCP after activating Dev Mode access.

4. Design Requirements

With a messy design, you might get nowhere. Or rather, you might get something, but fixing the errors will take longer than if you did everything manually.

The main recommendations for the design are:

Layers should be grouped logically, their names should correspond to the context, and the correct structure of frames/components must be maintained.
Layer and variable names should be clear, consistent, and reflect the element's role (e.g., color-primary, font-heading-lg, spacing-md).
Auto-layout is used.
Constraints are set for layers.
Layers don't overlap.
Alignment and spacing follow consistent rules.

When NOT to Use MCP

I wouldn't use MCP when the design is poor - layers aren't grouped and are chaotic, colors and text styles are scattered and inconsistent, text is split into separate layers. Also, don't waste time converting designs for complex components, components with multi-layered elements and special animations. Or when the volume of work is small and targeted - in this case, it's probably easier to work with components manually.

Conclusion

In this article, we looked at what converting a design into code looks like with AI and MCP. Of course, refining components remains a separate process. The ready code proposed by the AI requires careful review, correction, and in some cases, a complete rewrite. Often, it's easier to just create a component manually from the start than to try to get a result automatically.

And yet, it's impossible to deny that a properly configured MCP and correct interaction with it gives a powerful boost to frontend development. With skillful integration, the effort and time a developer spends on transferring and checking styles can be redirected towards architecture and logic. The main thing is not to rely blindly on the assistant. MCP is just an additional tool that helps speed up work, but the responsibility for code quality remains with the developer.

Author: Liya Vasilkova, frontend developer at ByteMinds

Setting Up a Frontend Build for HTML Email Templating with MJML

Byteminds Agency — Thu, 18 Dec 2025 10:18:12 +0000

In this article, we'll break down two key stages: first, we'll create a repository for email templating, and then we'll configure local test sending via SMTP.

Why go through all this?

On one of our projects, we actively use HTML emails. Initially, templates were placed directly in the backend microservices - scattered and with repetitive parts. This created difficulties in maintenance and email testing. We wanted to simplify the development process, and most importantly - make email templating and checking convenient.

And as we know, email templating is painful. It's like you're developing for Internet Explorer - if you even remember what that is.

Moving Emails to a Separate Repository

We decided to create a separate repository where all email templates would be stored. The backend would be able to pull them centrally.

The next step was choosing tools for templating and testing. We considered:

MJML
Maizzle
Foundation HTML

We wanted to write in a higher-level language, using pre-built components. With Maizzle and Foundation HTML, it seemed like we'd have to write more raw HTML code.

In the end, we settled on MJML - a markup language for email templates that compiles into full-fledged HTML, adapted for the specifics of email clients.

What is MJML and Why is it Convenient?

MJML is a language designed for HTML email templating, which compiles into regular HTML. This means you can write in an abstract syntax that then turns into HTML code with support for different mail clients. This eases adaptation for various mail clients and gives the ability to use:

responsive templating;
pre-built components;
code reuse with mj-include.

You can see how MJML code turns into HTML here.

Basic Project Setup

Let's go through the basic project setup - without delving into MJML syntax.

Install dependencies:

npm install mjml live-server concurrently

What each one does:

mjml - compilation MJML → HTML
live-server - starting a dev server with live reload (you can use any server)
concurrently - running commands in parallel

Configuring package.json

Add to scripts:

"scripts": {
  "start": "mjml --watch ./src/templates/**/*.mjml --output ./templates",
  "server": "live-server --host=localhost --watch=templates --open=templates --ignorePattern=\".*.mjml\"",
  "dev": "concurrently \"npm run start\" \"npm run server\"",
  "build": "mjml ./src/templates/**/*.mjml --output ./templates"
}

What each command does:

start - watches *.mjml files in src/templates/, compiles them to ./templates
server - starts a server and tracks changes in ./templates
dev - runs start and server in parallel
build - one-time template compilation without a watcher

Creating the First Template

Create a file example.mjml at /src/templates/example.mjml. All templates will be in the /src/templates folder. Add the following code to the file:

      </mj-column>
    </mj-section>
    <mj-section background-color="#ffffff">
      <mj-column>
        <mj-image src="https://placehold.jp/300x200.png" />
      </mj-column>
      <mj-column>
        <mj-text font-size="18px" font-weight="bold">Hello, world!</mj-text>
        <mj-text>This email was sent using MJML.</mj-text>
      </mj-column>
    </mj-section>
    <mj-section>
      <mj-column>
        <mj-button href="#" background-color="#4CAF50">Subscribe</mj-button>
      </mj-column>
    </mj-section>
  </mj-body>
</mjml>

Run npm run dev - and a browser will open with the HTML generated from MJML. Each time the template changes, the page will automatically update. It's also useful to create a ./src/parts folder for reusable layout components.

As a result, we'll get desktop and mobile versions.

In the ./src/parts folder, create reusable email parts:

./src/parts/global-settings.mjml

<mj-style inline="inline">
  body { background-color: #f0f4f6; font-family: Arial, sans-serif; }
  a { color: #1d5cdb; text-decoration: none; }
</mj-style>
<mj-attributes>
  <mj-text
    font-size="17px"
    line-height="24px"
    color="#000"
    padding-top="5px"
    padding-bottom="5px"
  />
</mj-attributes>

./src/parts/header.mjml

<mj-section>
  <mj-column>
    <mj-image
      src="https://placehold.jp/82x47.png"
      alt="Logo"
      width="82px"
      height="47px"
    />
  </mj-column>
</mj-section>

Let's include them in example.mjml and remove unnecessary styles:

<mjml>
  <mj-head>
    <mj-include path="../parts/global-settings.mjml" />
    <mj-title>Example</mj-title>
  </mj-head>
  <mj-body>
    <mj-include path="../parts/header.mjml" />
    <mj-section padding="40px 0 20px">
      <mj-column>
        <mj-text align="center" font-size="28px" font-weight="bold">Email built with MJML</mj-text>
      </mj-column>
    </mj-section>
    <mj-section background-color="#ffffff">
      <mj-column>
        <mj-image src="https://placehold.jp/300x200.png" />
      </mj-column>
      <mj-column>
        <mj-text font-size="18px" font-weight="bold">Hello, world!</mj-text>
        <mj-text>This email was sent using MJML.</mj-text>
      </mj-column>
    </mj-section>
    <mj-section>
      <mj-column>
        <mj-button href="#" background-color="#4CAF50">Subscribe</mj-button>
      </mj-column>
    </mj-section>
  </mj-body>
</mjml>

We get the result:

In summary:

We can globally set common styles and settings for components using global-settings.
We can similarly extract code parts, as done with header.
We develop and see changes in the browser in real-time thanks to the configured dev server.

Using Templates on the Backend (Go)

Our project backend is written in Go. The compiled email templates end up in the ./templates folder. From there, the backend can pull them and send emails. In our case, connecting templates looks like this:

In the project root - go.mod:

module gitlab.site.ru/front-html-email-templates

go 1.22.0

In ./templates/templates.go

package templates

import _ "embed"

//go:embed example.html

var Example string

When adding a new template, a similar variable needs to be added to templates.go.

Also, emails have variables that the backend substitutes using its templating engine. In our case, the syntax for variables is {{.variableName}}.

<mjml>
  <mj-body>
    <mj-section padding="40px 0 20px">
      <mj-column>
        <mj-text align="center" font-size="28px" font-weight="bold">{{.title}}</mj-text>
      </mj-column>
    </mj-section>
  </mj-body>
</mjml>

To understand what variables are needed in a template, we created a ./docs/templates folder where we store markdown files with the same name as the template and a description of which variables are used, for example:

## Candidate

Email template 'Application without a vacancy'

### Variables
- `{{.date}}` Application Date
- `{{.title}}` Vacancy Title
- `{{.region}}` Region
- `{{.name}}` Full Name
- `{{.phone}}` Phone
- `{{.email}}` Email
- `{{.comment}}` Comment
- `{{.resume_link}}` Resume Link
- `{{.year}}` Current Year

The variables themselves can be added to the files by the backend developer, and the frontend developer just needs to place them in the layout in the correct spots.

Local SMTP Testing

Let's write a simple JS script that will send our templates to a real email.

First, install the following packages:

npm install dotenv nodemailer

dotenv — package for loading .env files in JS;
nodemailer — package for sending emails with SMTP support.

After that, create a file ./send-test-email.js and add the code:

import nodemailer from 'nodemailer'
import dotenv from 'dotenv'
import fs from 'fs/promises'

dotenv.config()

async function sendTestEmail() {
  const transporter = nodemailer.createTransport({
    host: process.env.SMTP_HOST,
    port: process.env.SMTP_PORT,
    secure: true, // true for port 587, false for other ports
    auth: {
      user: process.env.SEND_FROM_EMAIL,
      pass: process.env.SEND_FROM_EMAIL_PASSWORD,
    },
  })gmail.com

  const htmlEmailString = await fs.readFile(
    `./templates/${process.env.TEMPLATE_NAME}.html`,
    'utf-8'
  )

  const mailOptions = {
    from: `Test Sender <${process.env.SEND_FROM_EMAIL}>`,
    to: process.env.SEND_TO_EMAIL,
    subject: 'Test HTML Email',
    html: htmlEmailString,
  }

  const info = await transporter.sendMail(mailOptions)
  console.log('Message sent: %s', info.messageId)
}

sendTestEmail().catch(console.error)

This is a simple implementation for sending emails via SMTP. We also need to create a .env file with the necessary variables:

TEMPLATE_NAME=email-confirmation
SEND_TO_EMAIL=test@byteminds.co.uk
SMTP_HOST=smtp.gmail.com
SMTP_PORT=587
SEND_FROM_EMAIL=test@gmail.com
SEND_FROM_EMAIL_PASSWORD=BcsftTdfdsf

TEMPLATE_NAME - the name of the template to be sent;
SEND_TO_EMAIL - where the email will be sent;
SMTP_HOST - SMTP host;
SMTP_PORT - port;
SEND_FROM_EMAIL - the sender's email address.
SEND_FROM_EMAIL_PASSWORD - the sender's email password.

Primarily, the TEMPLATE_NAME and SEND_TO_EMAIL variables change. For testing different templates and different mail clients.The other variables only need to be configured once.

After all the setup, to send an email, you need to run the script:

node ./send-test-email.js

For convenience, you can add a script to package.json. You can also implement support for bulk sending a template to different mail clients.

Conclusion

The current concept can be applied with other tools as well. As a result, we have:

a centralized repository for HTML emails;
email templating with best practices and reusable parts;
local SMTP testing.

It's important to keep in mind that templating can still break in old Outlook clients and with solutions like MJML where standard templates are provided. Even using best practices doesn't completely solve this issue. To avoid "breaking" in old solutions, you can use very trivial layout: simple texts and headings, no styling or visual elements.

Author: Dmitry Berdnikov

gRPC for Testers: Quick Start After REST

Byteminds Agency — Thu, 11 Dec 2025 12:05:39 +0000

REST API has long been the standard, but it has its limitations. When load increases, streaming scenarios appear, or business requires faster communication between services, REST stops being the ultimate solution. gRPC solves what REST cannot: it provides high data transfer speeds, supports streaming, and enforces a strict interaction structure. It is convenient to use in microservices, mobile, and IoT applications.

For a tester, this means one thing: knowing how to work with gRPC is shifting from a "nice-to-have" to an essential skill. If you haven't worked with this protocol yet, this article will help you understand its basics, how it differs from REST, the structure of .proto files, and most importantly - how to test gRPC services using Postman.

What is gRPC and Why is it Needed?

gRPC is a high-performance framework from Google. As a QA specialist, you don't necessarily need to dive into implementation details, but understanding how this protocol works and how to test it will definitely be useful.

To simplify, REST can be compared to paper letters sent in envelopes, while gRPC is like a phone call. Both are formats for communication between an application and a server, but with REST API, data is transferred in JSON or XML formats, which in our analogy can be equated to envelopes. This is okay and works, but not always fast or convenient.

gRPC proposes wrapping data in a binary protocol, which transmits data faster, has a smaller size, and is strictly structured. It uses Protocol Buffers (protobuf). Thanks to this, both sides participating in the information exchange know in advance what questions will be asked and what answers to expect. For a tester, this means less ambiguity and more predictability in verifications.

When we first implemented gRPC in a project, it unexpectedly turned out that Postman, by default, couldn't work with this protocol. We had to find workarounds - we tried BloomRPC, then grpcurl. In the end, we found a solution: uploading .proto files into a new beta version of Postman. It was a useful lesson - tools aren't always ready "out of the box," and it's important for a tester to have several alternatives on hand.

Key Advantages of gRPC

Why is gRPC usage increasingly common in product development? Here are the main reasons:

High performance thanks to the binary protobuf format.
Support for streaming: data can be transmitted not only in a "request-response" format but also as streams.
Cross-platform: gRPC can be used for projects in different programming languages.
Code autogeneration: client and server code is automatically generated from .proto files.

All of this leads to fewer misunderstandings with developers, clear rules for validation, and new testing scenarios - for example, for streaming.

Key Differences Between gRPC and REST

Moving from testing REST to gRPC implies conceptual changes in the process. Instead of endpoints and HTTP methods - methods and messages described in a contract. For convenience, let's compare them in a table.

Next, let's look in more detail at one of gRPC's advantages over REST - the presence of streaming.

Types of gRPC Calls

Unlike REST, which has the familiar GET/POST/PUT/DELETE, gRPC works with methods defined in a .proto file.

Four types of calls are supported:

Unary - one request, one response.
Server streaming - one request, stream of responses.
Client streaming - stream of requests, one response.
Bidirectional streaming - stream of requests, stream of responses.

When designing tests, it's important to consider that "one test - one request" isn't always suitable. For streaming, you need scenarios with multiple sequential messages.

But to understand which methods are available and what data can be transmitted in these calls, you need to understand how a .proto file is structured.

How a .proto File is Structured

This is a simple text file with a .proto extension. In it, we essentially agree on what data can be sent and received, and what methods the service has.

You can think of it as an instruction or contract between the service developer and those who use it (for example, QA specialists).

Usually, the .proto file is created by the backend service developer, because they know which methods the service must support, as well as what data is accepted and returned.

A tester can also open a .proto file to understand how to correctly form a request, suggest improvements (for example, add a field or change a data type), and, if desired, write their own .proto for learning or experiments.

Before moving on to the structure of a .proto file, let's make an important clarification.

gRPC indeed transmits data in the binary Protocol Buffers format, not JSON - this is why it is more efficient than REST in terms of speed and traffic volume. However, when testing via tools like Postman, BloomRPC, or grpcurl, you will see requests and responses in a human-readable format resembling JSON. This is a visualization of the binary data for humans. The tools automatically convert the binary stream into such "pseudo-JSON" to make it easier for you to work with the fields.

In our examples, we will also use this readable format - not because gRPC uses JSON, but so you can quickly understand the message structure.

Let's look at a simple example of a .proto file:

syntax = "proto3";

service HelloService {

  rpc SayHello (HelloRequest) returns (HelloResponse);

}

message HelloRequest {

  string name = 1;

}

message HelloResponse {

  string message = 1;

}

What's Inside:

Syntax Specification

syntax = "proto3";

Syntax indicates which version of the Protocol Buffers language we are using.
At the time of writing, the current version is the third - proto3.

Service Definition

service HelloService { rpc SayHello (HelloRequest) returns (HelloResponse); }

service HelloService - declaration of a service named HelloService.
You can think of a service as a class containing methods.
rpc SayHello (...) returns (...)- this describes a remote procedure call, where:

SayHello — the method name.
(HelloRequest) — what the method accepts (request type).
returns (HelloResponse) — what the method returns (response type).

In our example, the service has only one method, SayHello, which accepts a HelloRequest message and returns a HelloResponse.

Request Message Description

message HelloRequest { string name = 1; }

Message HelloRequest defines the data type for the request. Inside it:

string name = 1;

string - data type (string).
name - field name.
= 1 - sequence number (needed for serialisation).

This means: the client must pass a string field name.

Example:

Response Message Description

message HelloResponse { string message = 1; }

Message HelloResponse defines the data type for the response. Inside:

string message = 1;

a string that will contain the result.

In our case, the server will return a greeting string.

Example:

All of this works as follows: the client calls the SayHello method, in the HelloRequest it sends the name field, the server receives this field, forms a response, and in the HelloResponse it returns a string with a greeting.

If you know how to read and understand .proto files, you can easily grasp the data structure and suggest improvements to the API even at the design stage.

And now, it's logical to move on to the next question: what else does the service return besides useful data? Here we'll talk about gRPC status codes.

gRPC Status Codes: What a Tester Needs to Know

In gRPC, every response (even a successful one) is accompanied by a status code. These are not HTTP 200/404/500, but their own set of codes defined in the gRPC library. In total, gRPC has 17 predefined status codes, from 0 to 16, but we will consider only the most basic and commonly used ones.

Main gRPC Status Codes

It's important not only to verify the correctness of the data in the response but also to ensure the service correctly returns status codes in various scenarios.

gRPC in Postman: Practical Testing

Previously, Postman could only work with REST, but now - also with gRPC.

How it works:

Upload the .proto file into Postman.
Select the service and method.
Form the request (data is taken from the request structure in the .proto).
Look at the response and status code.

For example, for a simple service:

A request in Postman will contain the name field, and in response a greeting message will arrive.

Let's look at an example.

Create a new request → select the request type gRPC Request (not HTTP!).

Specify the URL, open the Service Definition tab, import the .proto file.

After importing the .proto file, all available methods the service can work with will become available for selection.

Select the method we need, and a JSON-like form with fields that need to be filled in will appear in the request body (all required fields are defined in our .proto file).

Click Invoke and you will see the response and status code.

Summary

gRPC is faster than REST, supports streaming, and enforces strict contracts.
For a tester, the key skills are: being able to read .proto files, check different call types, and work with tools (Postman, grpcurl, BloomRPC).
Don't forget about status codes: they help understand how a service behaves in error scenarios.
In practice, you may encounter pitfalls: not every tool supports gRPC as conveniently as REST.

By mastering gRPC, you will expand your arsenal: you'll be able to test not only REST services but also more modern microservice systems. And that means - you'll become a more in-demand specialist.

Author: Vasil Khamidullin

Understanding CORS: A Practical Guide

Byteminds Agency — Fri, 28 Nov 2025 11:30:36 +0000

Have you ever seen a message in your console like: "Access to fetch at '...' from origin '...' has been blocked by CORS policy"? CORS doesn't draw attention to itself when everything is working, but at a crucial moment, it firmly blocks unauthorized actions. For example, reading the response to a cross-origin request without the server's permission.

Web technologies allow us to perform banking transactions instantly, make payments in online stores, collect and process data - but the more actively websites communicate with each other, the more pressing the issue of security becomes.

CORS is a protection mechanism for cross-origin requests, but the first time I encountered this error, I didn't understand how to fix it. I tried adding the required header mentioned in the error message (we'll look at where to find these errors later), but that didn't help. I had to dig deeper: to understand what an origin is, how a simple request differs from a preflight request, why using a wildcard (*) doesn't work with credentials, and where CORS ends and CSRF begins (don't worry too much about these terms now, they will be explained throughout the article).

In this article, I will briefly answer questions about why the CORS policy was created, how it works, why a simple action like "setting a header on the backend" might not be enough, and what secure patterns to choose for the frontend.

To understand the logic behind CORS, we need to figure out where this security policy started - namely, with the Same-Origin Policy (SOP): what it allows, what it forbids, and why CORS wouldn't be needed without it.

What is SOP and Origin

It all started back in 1995 when everyone's beloved (or not so beloved) JavaScript appeared and its use was implemented on web pages. At that moment, the concept of a browser policy emerged, and it was called the Same-Origin Policy (SOP).

SOP is a fundamental principle of browser security, guaranteeing that scripts from one Origin cannot access data from another origin without explicit permission. Initially, SOP only protected access to the DOM (page structure) of other origins, but it was later extended to other sensitive objects (like cookies and global JS objects).

So, what is an Origin? An Origin (hereinafter referred to as Source) is a unique combination of scheme (protocol), domain, and port (see the diagram below). If at least one of these components differs, one Source will be different from another.

Examples of Matching or Non-Matching Origins

The comparison table below provides examples:

How SOP Works in Practice

Let's now break down a scenario step-by-step where the SOP policy might be triggered (Image above):

A user visits and requests resources located at https://www.a.com.
The loaded resources from https://www.a.com in the user's browser then initiate a request for resources located at https://www.b.com.
The browser checks the so-called Origin and, as seen in this case, the origins do not match, so the browser blocks access to the resources from https://www.b.com.

What Would Happen Without SOP

Why was SOP necessary in the first place? What's the benefit for me as a user? And if I'm a web developer, why should I keep this in mind and work around the restrictions?

It's hard to argue with the primary reason: security.

Let's imagine SOP doesn't exist and play out a scenario (image above), disastrous for both the user (who becomes vulnerable) and the developer (whose product loses trust):

The user logs into their bank at bank.com (a session cookie is saved in the browser).
They then visit a malicious website, bad-site.com, which contains a hidden malicious script.
This script initiates a request with the session cookies to bank.com on the user's behalf.
As a result, the malicious script receives a response from the bank without your knowledge!

Without SOP, this script could get the user's recent transaction list, create a new transaction, etc. This is because, according to the original concept of the World Wide Web, browsers are obliged to add authentication data like session cookies and authorization headers at the platform level when making requests to the bank's site, based on that site's domain.

Let's return to our reality, where a protection mechanism against such nuisances exists (image below). Steps 1-3 from the disastrous scenario would be the same, but at step 4, SOP would block access to the requested resources.

It was precisely to prevent such attacks that the Same-Origin Policy was introduced: browsers started automatically blocking scripts from one Origin from accessing data from another.

Important: Although JavaScript indeed doesn't have direct access to the bank session cookies, it can still send requests to the bank's website using those bank session cookies, as in the situations on images above.

Experienced readers might say you can simply set the HttpOnly flag on cookies. However, this flag only became a standard in 2002. Others might mention SameSite. But it only appeared in 2016 and became a standard only in 2019-2020.

SOP restricts reading data from a foreign origin, but it does not block the sending of requests to foreign domains. The browser would still automatically include cookies for bank.com when submitting a form to bank.com - it's just that the script from bad-site.com wouldn't find out what the bank returned. SOP only prevents the attacker from reading the response and confirming the attack worked. To protect against such scenarios on the server side, additional measures are needed (e.g., CSRF tokens in forms, setting appropriate SameSite and HttpOnly values, etc.).

This is the Same-Origin Policy (SOP) in the browser, designed to protect the user. It doesn't seem too complicated overall, right? The user doesn't need to think about it because the browser developers have already thought about it and implemented a protection mechanism. The developer also doesn't need to worry about it specifically in their code - it's enough to follow the established rules.

Restrictions Imposed by SOP

So, SOP imposes a number of strict restrictions on interaction between resources from different Origins:

Blocking Access to Page Content. A script cannot read or modify the content of a page from another domain. For example, JavaScript from site-a.com cannot access the DOM, cookies, localStorage, or other data of a page on site-b.com.
Frame Isolation. If an <iframe src="..."> from a foreign domain is embedded in a page, the parent script cannot access iframe.contentWindow.document of that frame (and vice versa) access will be denied as long as their origins differ.
Blocking Access to HTTP Responses via XHR/Fetch. The browser blocks receiving the response to AJAX requests sent by a script to another domain. That is, you can send a fetch to a third-party API, but if their Origins are different, the browser will not provide the response to the script.
Exceptions (Allowed Loads). SOP restricts access to data from third-party origins, not the loading of resources themselves. The browser can load images, styles, scripts, media, and frames from another domain without errors and use them as-is: display an image, apply a style, execute a script, play a video, render an iframe. However, the page's JavaScript is not allowed to read the internal content of these resources (image pixels, style rules, frame DOM, video bytes, etc.) unless the resource's server explicitly permits access via CORS.

Essentially, SOP says: "you can't read others' data," and this provides basic isolation. But the real web has long been multi-domain: we pull fonts from CDNs, call external APIs, facilitate communication between microservices. How to make such exchanges legitimate and secure without breaking isolation? This is where CORS comes onto the stage - a set of rules for coordinated access between different origins.

The Emergence and Role of CORS

SOP remains the foundation of browser security. But to allow controlled crossing of boundaries between origins, Cross-Origin Resource Sharing (CORS) was standardized: it adds explicit rules and headers to SOP, allowing the browser, based on server responses, to precisely grant access to clients from other Origins.

In essence, CORS is a browser technology that grants web pages access to resources from another domain under certain conditions.

How the CORS Policy Works

Let's say we have a frontend application on one domain (https://www.a.com) that wants to request data from an API on another domain (https://www.b.com). By default, SOP forbids the script from reading the response. However, the CORS standard defines a number of HTTP headers that the server (domain B) can use to tell the browser: "I trust domain A, you can let it read the response." This happens through embedded headers that the browser uses to regulate access between Origins.

Now let's look at how CORS works in more detail and see which headers the browser relies on. When the browser makes an AJAX request (Fetch or XHR) to a third-party resource, it automatically adds an Origin header to the request, indicating the current origin of the page. For example, a request from the page http://www.a.com/page.html to the resource http://www.b.com/data.json would look like this (image below, step 2):

GET /data.json HTTP/1.1 Host: www.b.com Origin: http://www.a.com

The server www.b.com, having received such a request, can decide to allow access. To do this, it must include the Access-Control-Allow-Origin header in the response, with a value of either the specific requesting domain-origin or * (the asterisk means "allow for any origin"). For example:

Access-Control-Allow-Origin: http://www.a.com

If the browser sees Access-Control-Allow-Origin in the response with the required origin (or *), it will not block the script's access to the received data. Otherwise if such a header is missing - blocking will occur: the JS code will get a network error instead of the data.

Besides the main permitting header, the CORS standard defines other access control headers:

Access-Control-Allow-Credentials– controls access to resources considering authorization. If this header is set to true, the browser will allow access to such a response. Important: when using Allow-Credentials: true, the Allow-Origin value cannot be * - you must explicitly specify the specific domain, otherwise the browser will ignore the response.
Access-Control-Allow-Methods – a list of HTTP methods allowed when accessing the resource. If the script plans to send not only GET but, say, PUT or DELETE, the server must list them in this header, otherwise the browser will deny access.
Access-Control-Allow-Headers – similarly, a list of non-standard headers allowed in the request. For example, if the frontend wants to send a header like X-Custom-Header or Authorization, the server must explicitly allow them via this header.
Access-Control-Max-Age – the time (in seconds) for which the results of the preflight check can be cached. This header allows the browser to avoid making extra preflight checks (more on them later) for repeated requests within the specified time.
Access-Control-Request-Method – a header sent in the preflight request (more on that later) informing the server of the intended method of the main request.
Access-Control-Request-Headers – a header sent in the preflight request (more on that later) informing the server of the list of non-standard headers the client wants to send in the main request.

But I want to note that requests can be different when viewed through the lens of CORS. This brings us to concepts like "simple" requests (see the image above) and "complex" ones (see the image below) (requiring a preliminary check via a preflight request).

Simple and Complex Requests in CORS

A simple CORS request is one that does not require an additional "handshake" with the server. The browser sends it immediately, only adding the Origin header, and expects a direct response with Access-Control-Allow-Origin.

So how is a request determined to be complex? What rules does the browser rely on to determine the type of request? The standard defines characteristics for simple and complex requests.

If all the requirements for a simple request are met, it is considered simple and the browser will send it directly. However, if just one condition is violated for example, specifying an Authorization header for a token, or using the PUT method the browser will, before the main request, execute a special preliminary request (preflight) with the OPTIONS method to the same URL. This OPTIONS request does not contain a body but includes the headers Access-Control-Request-Method (with the method of the main request) and Access-Control-Request-Headers (a list of non-standard headers, if any).

Thus, the browser asks the server if it allows a request with such parameters. The server must respond to the preflight request with a status of 200 (or 204) without a body, but with the previously mentioned headers: Access-Control-Allow-Methods (listing allowed methods, e.g., PUT), Access-Control-Allow-Headers (listing allowed non-standard headers, e.g., Authorization, X-Custom-Header), and the mandatory Access-Control-Allow-Origin (specifying the origin or *).

If the browser receives a favourable response, it will proceed and execute the real request (e.g., PUT with the specified headers). And in response to the real request, the server must again include Access-Control-Allow-Origin (and, if needed, Access-Control-Allow-Credentials) so that the browser delivers the data to the script.

Important note: This entire exchange happens automatically, without intervention from the front-end developer but if at any step the server doesn't return the necessary headers, the browser will reject the request.

CORS Errors

Developers can see CORS errors only through the browser console - JavaScript code, in case of policy violations, receives only a generic network error. In the console, it will be indicated which header is missing or what exactly was blocked by the policy (Origin, method, header, etc.). To resolve the problem, you need to correctly configure the headers on the server.

For example, errors of this nature can occur:

When requesting from origin http://localhost:3000 to another origin http://localhost:4000, if the PUT method is not allowed, an error like this will appear in the console:

When requesting from origin http://localhost:3000 to another origin http://localhost:4000, if the value of the Access-Control-Allow-Credentials header is not set to true:

When requesting from origin http://localhost:3000 to another origin http://localhost:4000, if the request header custom-header is not allowed:

Okay, we've seen how the browser decides "to allow or not." But what other methods of cross-origin interaction exist and why shouldn't they be confused with CORS? Let's discuss that next.

Alternatives and Related Mechanisms

Besides the discussed SOP and CORS, the following mechanisms can also be mentioned:

Bypassing SOP via document.domain. Historically, a workaround was devised for subdomains: pages aaa.example.com and bbb.example.com could both execute a script assigning document.domain = "example.com", and then the browser would consider them the same origin. However, this approach is now outdated and declared unsafe. For example, Chrome plans to completely disable the ability to set document.domain because it undermines SOP protection (link to MDN).
Interaction via window.postMessage(). This API allows scripts from different origins to communicate safely. For example, a page from domain-a.com can send a message to an embedded iframe from domain-b.com by calling iframe.contentWindow.postMessage(data, targetOrigin). If the targetOrigin matches (or "*" is specified for any), then on the domain-b.com side, the iframe will catch the message event and can read the data. An important property - neither the parent nor the iframe gains access to the other's DOM or JS objects; they only exchange string messages. postMessage is the primary way to integrate between different applications within the same window/tab (e.g., between a payment widget and a website).
JSONP (JSON with Padding). Before CORS became widespread, this was a popular trick for getting data from another domain. The gist: the site inserts a tag <script src="https://other.com/data?callback=parser"> into the page. The server returns JavaScript code that calls the global function parser(...) with the JSON data inside. Because the <script> tag is not blocked by SOP (the script will execute), the data "leaks" into the function call on the first site's side. Disadvantages of JSONP - it only works for GET requests and carries risks (execution of third-party code). Nowadays, JSONP is hardly used, having given way to CORS, which supports any methods and doesn't allow direct execution of foreign code.

WebSockets. Interestingly, for WebSocket connections, SOP in its usual form does not apply. A page from JS can attempt to connect to wss://another-domain.com/socket the browser will allow this. However: when establishing the WS connection, the browser still sends the Origin header in the handshake. The WebSocket server must check this header itself and decide whether to allow this origin. Otherwise, an attacker could bypass SOP and establish communication with a private server. Thus, security for WS is the responsibility of the server: the browser trusts it and does not block connection attempts.
Resource Loading Control (CORP, COEP, COOP). New standards introduce additional headers to enhance isolation. For example, Cross-Origin Resource Policy (CORP) allows a server to declare that its resources (scripts, images, etc.) should not be loaded on third-party sites. If an image with CORP=same-site is attempted to be inserted via <img> on a foreign site, the browser will block it entirely. This helps prevent side-channel attacks and information leakage through hidden resource inclusion. Cross-Origin Opener/Embedder Policy (COOP/COEP) - even more advanced headers used for isolating contexts (e.g., to enable shared memory sharing, like SharedArrayBuffer, between tabs of the same site, they must be completely isolated from outsiders). These topics are beyond the scope of this overview, but mentioning them shows how the idea of controlling interaction between sites is evolving.
Private Network Access (PNA). Browser developers continue to enhance security policies. For example, in 2022, the Private Network Access (PNA) mechanism appeared - an extension of CORS for protecting local networks. Chrome was one of the first to implement PNA: now if a script on a website from the internet tries to access a resource in a private network, before the actual request, the browser will send a special preliminary request with the header ([Source link]):

Access-Control-Request-Private-Network: true

The local server (router) must respond with the header:

Access-Control-Allow-Private-Network: true

otherwise the browser blocks the connection. This measure aims to prevent attacks where attackers used the victim's browser for unauthorised access to devices on their local network.

What exactly should we take away from all this? Next, we'll formulate key points and a minimal checklist.

Summary and Practical Conclusions

The Same-Origin Policy has been the foundation of web security for almost 30 years. Thanks to SOP, our browsers isolate tabs and frames from each other, preventing sites from stealing each other's data. At the same time, the modern web is impossible without the integration of different services and this is where CORS comes in handy. This mechanism carefully extends SOP, allowing safe data exchange between trusted domains. To work effectively with CORS, a developer needs to understand which headers to configure on the server and why the browser blocks a particular request. To summarize, let's note the key points:

SOP blocks scripts from accessing foreign content. Don't trust solutions that try to disable SOP - in modern browsers, this is impossible without compromising security.
CORS is a tool in the hands of the server-side developer. By correctly setting the headers (Origin, methods, headers, credentials), you tell the browser: "this request can be trusted," and the browser will comply.
When debugging CORS issues, carefully look at the messages in the browser console - they will hint at which header is missing.
Always restrict access to the minimum necessary: specify concrete origins instead of *, allow only the necessary methods and headers. This reduces the chance of your API being abused.
Security is evolving: besides CORS, study other mechanisms (CSRF tokens, SameSite cookies, CSP, etc.) to build truly secure applications.

Understanding SOP and CORS will allow you to work confidently with APIs, avoid annoying "Blocked by CORS" errors, and protect user data from most simple attacks on the web. This is mandatory knowledge for every web developer.

Author: Bair Ochirov

How I Started Writing Unit Tests for Vue Components - Part 2

Byteminds Agency — Fri, 21 Nov 2025 09:48:30 +0000

So, it's been a year since the last article, and a lot has changed. In this one, we're going to talk about integrating with Mock Service Worker (MSW). I'll also describe what I tried to implement in my quest for system resilience - what worked out and what didn't.

So, did my tests actually help me?

I can't say the time investment paid off in spades, but one thing's for sure - it definitely wasn't a waste of time.

Here are the main areas where the tests really proved their worth:

When contracts were lost or changed;
Fixing the fallout from merge conflicts (given the quirks of our processes, this is the most common scenario);
Refactoring (it's hard to be objective here since our project's test coverage isn't huge, but before any refactoring, I try to at least cover the code with local tests).

Then again, all those fancy things like Cursor with their powerful autocomplete freed up some time, so why not spend a bit of it on tests?

The Fight for Reliability, or Reality Strikes Back

Let me start with what didn't work out.

The first thing I tried was implementing E2E tests with Playwright. You know, testing business logic in the browser by simulating real user actions.

In our existing project, this turned out to be really tough. The main problem was setting up the initial test data. In my case, that meant the database. It needed to be as small as possible, but still have all the necessary data for testing.

In theory, it sounds simple: take a database, tweak the data, create a Docker image, and boom - you're golden. Well, I got stuck at the very first step of preparing that database. It requires a firm decision and a coordinated effort, meaning help from the backend team and DevOps (who are always busy). In the end, on my project, we shelved the idea for the time being.

I also tried replacing actual backend interaction by mocking API requests directly within Playwright, but that felt like a dead end. Maintaining yet another set of mocks (on top of the MSW we already had) combined with the slow browser startup times just didn't seem rational, unless for some very specific tasks.

About Unit Tests and MSW

All in all, I decided to focus on unit tests (which, in the classic sense, are more like integration tests in our context). They're fast, isolated, simple, and reliable.

To mock network interactions, I set up MSW (Mock Service Worker). This later allowed us to practice contract-first programming and parallel development.

So, first you install MSW (the official guide is your best friend here).

Then, I moved the vite configuration for it into vitest.workspace.js (note: in new versions DEPRECATED). This isn't mandatory, but it's convenient if you need to separate node and browser environments.

import { defineWorkspace } from 'vitest/config';

export default defineWorkspace([
  'packages/*',
  {
    extends: './vite.config.js',
    test: {
      environment: 'jsdom',
      name: 'unit',
      include: ['src/**/*.spec.{ts,js}'],
      deps: {
        inline: ['element-plus'],
      },
      setupFiles: ['./src/mocks/setup.ts'], // path for the msw config
    },
  },
]);

Since it's an independent service, I put it in a mocks folder, so it's easy to cleanly remove if needed.

import { server } from './server.ts';
import { afterAll, afterEach, beforeAll } from 'vitest';

beforeAll(() =>  return server.listen({ onUnhandledRequest: 'warn' });
afterAll(() => server.close());
afterEach(() => server.resetHandlers());

user/handlers.ts

import { GET_USERS } from '@/api/constants/APIEndPoints.js';
import { HttpResponse, http } from 'msw';
import { USERS_FAKE_RESPONSE} from './fixtures.ts';

export const handlers = [
  http.get('*' + GET_USERS , () => {
    return HttpResponse.json(USERS_FAKE_RESPONSE);
  }),

];

Now, whenever a call is made to the URL defined in the GET_USER identifier, it will return the value stored in USER_FAKE_RESPONSE.

Interestingly, MSW, especially with its plugins, can generate handlers from an openApi.json file, which can cover all your API requests. It can also use faker.js to generate response data with fake values.

I'm not a big fan of that approach myself (it can complicate parallel work), so I prefer to create response fixtures and handlers manually, and then fill them in - even using AI helpers sometimes - which results in more human-readable responses.

export const USER_FAKE_RESPONSE = {
  items:[
    { firstName: 'John' , lastName: 'Smith'}
    { firstName: 'Willy' , lastName: 'Willson'}
  ]
}

Using it in Tests

For a clear example, let's imagine we have a component with a button to fetch users and a block to display the response. A traditional test might look something like this (a detailed test was in the previous article; this is just a schematic).

import * as USER_API from 'some api folder'
let wrapper

const createComponent = (params {}) => {
  wrapper = shallowMount(OurGetUsersComponent, {
    props: {
      ...params.props,
    },
    global: {
      renderStubDefaultSlot: true,
      stubs: {
        ...params.stubs,
      },
    },
  });
};

test('Handling user retrieval when the Find button is clicked', async () => {
const spyGetUsers =  vi.spyOn(USER_API, 'getUsersRequest').mockImplementation(() =>{  items:[
    { firstName: 'John' , lastName: 'Smith'}
    { firstName: 'Willy' , lastName: 'Willson'}
  ]}) 

  createComponent ()
  const buttonNode = wrapper.find('.button') //not a very good selector, but we only have 1 button
  await buttonNode.trigger('click');

  await flushPromises();
  expect(spyGetUsers).toHaveBeenCalled(); //here you can also check the parameters


  expect(wrapper.text()).toContain('Smith')
  expect(wrapper.text()).toContain('Willson')

});

That approach works, but what if we need to test the behavior when the server returns an error? For example, when a 500 error triggers a toast notification saying, "The server is temporarily unavailable, please try again later."

This is exactly where MSW comes to the rescue.

import { server } from '@/mocks/server';
import { http, HttpResponse } from 'msw';
import { USER_FAKE_RESPONSE } from '...fixtures'
import * as MESSAGE_MODULE from "utils"
import { GET_USERS } from '@/api/constants/APIEndPoints.js';

let wrapper

const createComponent = (params {}) => {
  wrapper = shallowMount(OurGetUsersComponent, {
    props: {
      ...params.props,
    },
    global: {
      renderStubDefaultSlot: true,
      stubs: {
        ...params.stubs,
      },
    },
  });
};

test('Handling user retrieval when the search button is clicked', async () => {
const spyGetUsers =  vi.spyOn(USER_API, 'getUsersRequest') // the implementation already exists in MSW and doesn't need to be duplicated here

  createComponent ()
  // it's better to search the same way as the user  
  const buttonNode = wrapper.findAll('.button').filter(item=>item.text()=="Search")[0] 
  await buttonNode.trigger('click');

  await flushPromises();
  expect(spyGetUsers).toHaveBeenCalled(); // This step might be redundant since the result is what matters to the user

  expect(wrapper.text()).toContain(USER_FAKE_RESPONSE.items[0].lastName)
  expect(wrapper.text()).toContain(USER_FAKE_RESPONSE.items[1].lastName)

});

test('Handling server errors when retrieving users', async ()=>{
spyMessage = vi.spyOn(MESSAGE_MODULE , 'showErrorMessage')

  server.use(
    http.get('*' + GET_USERS, () => {
      return new HttpResponse(null, { status: 500 });
    }),
  );
  createComponent ()
  const buttonNode = wrapper.findAll('.button').filter(item=>item.text()=="Search")[0] 
  await buttonNode.trigger('click');

expect(spyMessage ).toHaveBeenCalledWith({message: 'The server is temporarily unavailable, please try again later' });

})

This way, you can make your unit tests a little more honest and your team's capabilities a little broader.

Author: Dmitry Simonov

Performance Issues in Web Services: A Practical Guide to Identification and Resolution

Byteminds Agency — Fri, 31 Oct 2025 12:25:31 +0000

In the realm of web development, performance is frequently treated as an afterthought—a quality to be optimised after core functionality is delivered. This approach, however, is fundamentally flawed. Performance is not a feature; it is a foundational requirement, as critical as security, accessibility, or functional correctness. Clients may not explicitly demand a response time of ‘X milliseconds,’ but they will undoubtedly express dissatisfaction if a site feels sluggish or unresponsive. This guide provides a structured approach to integrating performance thinking into the development lifecycle, ensuring that web services are robust, efficient, and scalable from the outset.

1. Integrating Performance from the Initial Stages

The most effective method for ensuring high performance is to consider it during the initial architecture and design phases. Proactive planning is exponentially more effective than reactive optimisation. When performance is an afterthought, developers often encounter deeply embedded inefficiencies that are costly and time-consuming to rectify. Common issues include components that generate excessive database queries, a lack of caching strategy, and architecture that cannot scale under load.

Treating performance as a core skill involves cultivating a mindset of constant vigilance. Developers should not engage in premature optimisation but should instead learn to identify potential bottlenecks during the design and implementation phases. This includes questioning the necessity of each database call, considering the weight of third-party scripts, and planning for caching strategies before writing the first line of code.

2. Defining Clear Performance Objectives

Vague expectations like “it should be fast” are insufficient for guiding development. Teams must establish clear, measurable performance goals. For front-end performance, metrics such as Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS) (collectively known as Core Web Vitals) provide a user-centric benchmark for quality.

For server-side performance, a widely accepted standard is that the backend should deliver HTML content in under 200 milliseconds for the vast majority of requests, even under typical load. This target allows sufficient time for the browser to download assets, render the page, and become interactive without frustrating the user. Establishing these benchmarks early creates a shared understanding with clients and provides a clear target for the development team.

3. Estimating and Planning for Load

A critical yet often overlooked step is estimating the expected traffic a service must handle. For existing businesses, historical data from analytics platforms (e.g., Google Analytics) is invaluable. Key metrics to analyse include:

The busiest month and day in terms of traffic.
The peak hour of activity.
The number of concurrent users during these peaks.

For new projects without historical data, estimation requires a dialogue with the client. Essential questions include:

Who is the target audience?
What is the expected number of daily and monthly active users?
What are the conversion goals (e.g., sales, sign-ups)?
Are there anticipated periods of high traffic, such as seasonal promotions or marketing campaigns?

With these numbers, you can build a simple chain: if the site needs to generate 10,000 enquiries per month, and the conversion rate, according to the client, is 1%, then you need about 1,000,000 sessions per month. Dividing this by days and estimating the average duration of one session is enough to roughly understand how many people might be on the site simultaneously.

For example, if there are ~33,000 sessions per day, and each lasts an average of 1 minute, then at any given time, approximately 20–30 people could be on the site concurrently. These are concurrent users—the number of sessions happening in parallel.

There's nothing complicated about this model. But if you don't build it at all, it will be difficult to explain later why the site went down during an advertising campaign or crashed on launch day. Crucially, these assumptions must be documented and discussed with the client to ensure alignment and manage expectations.

4. Proactive Identification of Bottlenecks

Waiting for a quality assurance team to discover performance issues is a high-risk strategy. Developers should adopt tools and practices for self-testing during development.

Local Profiling: Simple checks during development can reveal significant problems, such as pages taking tens of seconds to load or components making redundant API calls.
Load Testing Tools: Frameworks like K6, Gatling, or Locust allow developers to simulate virtual users and measure a system’s behaviour under load. Writing a basic test script is straightforward and can be accomplished quickly, often with the help of AI assistants.
Synthetic Monitoring: Running a script to crawl a site’s main pages (via its sitemap) on a “cold” startup can uncover issues with slow database queries or missing caches before they impact real users.

The goal is not to become a performance engineer but to develop a habit of verifying that one’s code behaves efficiently under expected conditions.

5. Common Sources of Performance Issues

Performance bottlenecks often originate in common, site-wide components. Identifying these early is key:

Global Components (Header, Footer, Navigation): Fetching this rarely changing data from a CMS or database on every page request is inefficient. This content should be heavily cached or statically generated.
Dynamic Elements (Breadcrumbs, User Data): Building breadcrumb trails through sequential database queries or rendering user-specific data (e.g., cart items) on the server can cripple performance. These should be optimised with pre-computation or moved to the client side where possible.
Search and Filtering: Implementing complex filters and search functionality with direct SQL queries is a common mistake. This is a solved problem; dedicated search engines like Elasticsearch or Algolia are designed for this purpose and offer superior performance.
Metadata and Redirects: Generating meta tags (e.g., for multi-language support) and processing large redirect lists on every request adds significant overhead that can be mitigated through caching.
Asset Optimisation: Serving unoptimised images or processing them “on-the-fly” consumes substantial resources. Images should be optimised, resized, and served in modern formats (WebP, AVIF) as part of the build process.

All these things are simply a consequence of no one thinking during implementation about how the component would behave under load. And later, it becomes a common problem. But almost always, the reason is the same: an element that should have been light turned out to be heavy, and it wasn't cached. And since it appears on many pages, everything starts to slow down.

6. Implementing a Strategic Caching Layer

Caching is the most powerful tool for improving performance and should be architectured into an application, not bolted on later.

CDN (Content Delivery Network): Used to cache static assets (JS, CSS, images) and even entire HTML pages at geographically distributed edge servers.
Output Cache: Caches the fully rendered HTML output of a page, allowing the server to bypass the entire application logic for subsequent requests. This is highly effective for pages that are the same for many users.
Data-Layer Cache: Stores the results of expensive database or API queries in a fast in-memory data store (like Redis), preventing repeated calls to the primary database.

A well-designed caching strategy dramatically reduces server load, decreases response times, and improves scalability. While cache invalidation can be complex, most modern web frameworks provide robust tools to manage it effectively.

7. Fostering a Culture of Performance

Ultimately, ensuring performance is not the sole responsibility of a team lead or architect; it is a collective responsibility shared by every developer. Cultivating a “performance mindset” involves:

Education: Ensuring all team members understand common pitfalls and best practices.
Tooling: Providing integrated tools for profiling and testing.
Accountability: Encouraging developers to take ownership of their code’s efficiency by asking simple questions before committing: “Are there unnecessary queries?” “Can this be cached?” “How will this behave with 100 concurrent users?”

Conclusion

Building high-performance web services is an achievable goal that requires a deliberate and proactive approach. By integrating performance considerations from the very beginning, defining clear metrics, estimating load, proactively testing for bottlenecks, and implementing a strategic caching layer, teams can deliver experiences that are not only functional but also fast and reliable. This shift from reactive fixing to proactive building is what separates adequate services from exceptional ones. In today’s competitive digital landscape, performance is not just a technical concern—it is a fundamental business imperative.

Author: Dmitry Bastron

Setting SMART Goals for Digital Product Success

Byteminds Agency — Fri, 27 Jun 2025 07:41:26 +0000

In digital product development, vague aspirations such as "improve user experience" or "increase engagement" often lead to wheel-spinning rather than progress. This is where SMART goals transform abstract ideas into actionable, results-driven objectives.

Why SMART Matters in Digital Product Development

SMART — Specific, Measurable, Achievable, Relevant, and Time-bound — is a framework that clarifies goal-setting. For product teams, it’s not just a project management framework, it’s a way to align daily tasks with strategic outcomes.

Each component of SMART helps teams focus clearly on their tasks:

Specific
Instead of: "Make the app faster."
SMART version: "Reduce app load time from 4 seconds to under 2 seconds for 95% of users."
Why it works: Eliminates ambiguity so developers, designers, and stakeholders share the same understanding.

Measurable
Instead of: "Improve onboarding."
SMART version: "Increase Day-1 retention from 40% to 60% by streamlining the signup flow."
Why it works: Metrics provide a clear benchmark for success.

Achievable
Instead of: "Rebuild the entire backend in one sprint."
SMART version: "Migrate the payment module to a more scalable architecture within three sprints."
Why it works: Balances ambition with realistic resource allocation.

Relevant
Instead of: "Add social media integrations."
SMART version: "Implement Twitter/X login to reduce signup friction for our target B2B users."
Why it works: Ensures every task relates to business or user needs.

Time-bound
Instead of: "Redesign the dashboard."
SMART version: "Launch the new dashboard UI by Q3 to support upcoming enterprise feature releases."
Why it works: Deadlines create urgency and prevent scope creep.

Using SMART goals minimizes misunderstandings, increases transparency, and aligns tasks strategic objectives.

SMART Goals Throughout the Digital Product Lifecycle

From initial concept to mature product, SMART goals provide structure and alignment across all phases — from discovery to scaling and post-release.

Early in development, it is important to set benchmarks that will help identify real user needs and define the direction of development. For example, during discovery, you can formulate a goal: “Collect 30 user interviews within three weeks to confirm the hypothesis about the need for a new feature.”

Impact Mapping and User Story Mapping will also help conduct a high-quality Discovery phase for a digital product. In combination with SMART goals, these practices will help connect goals with real user scenarios and form a solid foundation for the product roadmap.

For MVP and launch phase, goals may look like this: “Achieve 1,000 registrations in the first month after release” — this is a specific, measurable, and achievable goal with a business-oriented result.

When scaling or optimizing processes, SMART maintains focus. For example: “Reduce technical debt by 20% per quarter by refactoring priority modules.” SMART goals should be used in digital product management at all stages to achieve sustainable and predictable results.

Unlike traditional project management, where goals often remain static, digital products thrive when SMART criteria evolve with each lifecycle phase — always specific, always measurable, but continuously refined based on real-world learning.

SMART Goals vs. General Tasks

General statements like “improve the application” or “increase productivity” lack clarity and measurability.

SMART goals, on the contrary, help to eliminate vague task statements:

Bad: “Make the website faster”
Good (according to SMART): “Reduce the average load time of the main page by 30% within 2 months”

Another benefit of SMART goals is that they work on the motivation and involvement of the team, since each participant in the product development process understands where the project is heading and how progress is measured.

SMART goals act as both compass and speedometer — keeping teams focused while proving they're moving in the right direction.

SMART Goals in Action: Practical Examples for Digital Teams

The best way to understand effective goal-setting is through examples. Here's how different roles can apply the SMART framework to drive measurable results.

Product team

Let's say you're preparing to launch a new feature. Instead of an abstract goal of "add a category filter," you can set a SMART goal:

"Implement category filtering in the catalog and test it on 80% of users during the current sprint to increase conversion by 15%."

Here, there is specificity, a deadline, and a connection to product metrics.

Development team

Working with technical debt is often postponed if there is no clear goal. Example:

"Optimize API requests by reducing the average response time from 700ms to 300ms in 3 weeks" is a clear and measurable task that fits into the backlog and affects the user experience. Agreed, this is much better than telling the team to simply refactor a certain module of the application.

Business goals

For growth, not only features are important, but also metrics like LTV or CAC. A good SMART goal:

"Reduce the cost of customer acquisition (CAC) by 20% per quarter by testing new advertising channels."

The numbers, the reason, and the deadline are all there.

Whether you're shipping features, optimizing systems, or driving growth, SMART goals turn intention into action.

Crafting Effective SMART Goals: A Step-by-Step Guide

Transforming vague ideas into actionable objectives is simpler than you might think. Follow this five-step framework to create powerful SMART goals for your digital product team.

Step 1: Be Specific
Weak: "Improve user experience"
Strong: "Implement push notifications for order confirmations"
Why it matters: Specificity eliminates guesswork. Everyone understands exactly what needs to be built.

Step 2: Ensure Measurability
Weak: "Get more user feedback"
Strong: "Collect 200 in-app reviews after launching the new rating feature"
Key benefit: Quantifiable targets let you track progress objectively.

Step 3: Verify Achievability
Unrealistic: "Redesign entire platform in one week"
Practical: "Launch new registration flow by January 25 with the current dev team"

Step 4: Confirm Relevance
Questionable: "Add social media sharing to admin dashboard"
Valuable: "Implement one-click export for sales reports to reduce manager workload"

Step 5: Set Time Boundaries
Vague: "Complete sometime this quarter"
Effective: "Deploy to production by May 15"

This structured approach turns overwhelming "to-dos" into clear, motivating objectives that drive real results.

SMART vs OKR vs KPI: Choosing the Right Framework

Understanding the differences between these three popular methodologies is crucial for effective product management. Let's clarify when and how to use each approach — and how they can work together.

SMART is a way to clearly and understandably set a goal. It is great for team and individual tasks, especially if you work in an agile team or a startup, where focus is more important than large-scale strategies.

OKR (Objectives and Key Results) is about big ambitions. You set an inspiring goal (Objective) and 2-4 key results to measure your progress. SMART formulations fit perfectly into OKR key results. You can think of OKR as an add-on to SMART goals. OKR is about a strategy for the year, SMART is about sprint planning.

KPI (Key Performance Indicators) are metrics used to track ongoing performance and efficiency. They answer the question: “How well are we doing?” For example, a KPI could be: “Reduce the churn rate to 10%.”Some KPIs can be part of a SMART goal.

In summary:

Need to solve a specific problem? → SMART
Setting a company-wide strategy? → OKR
Tracking ongoing performance? → KPI

These frameworks don’t compete — they complement each other in different areas of product management. Used together, they create a powerful system for turning vision into measurable results.

Common SMART Goal Pitfalls and Solutions

Even experienced product teams often stumble when implementing SMART goals. Here are three critical mistakes that undermine digital product initiatives — and how to fix them.

1. Unrealistic ambitions that backfire

Problem Example: "Increase conversion rates by 300% within 30 days"
Why It Fails: While aggressive targets can inspire, impossible goals destroy morale. Teams quickly recognize when leadership prioritizes wishful thinking over achievable outcomes.
SMART Solution: "Grow conversions by 18% this quarter through checkout flow optimization and targeted email campaigns"
SMART implies realism and achievability, not a flight of fancy.

2. Lack of metrics
Problem Example: "Improve the user interface"
Why It Fails: Without measurable criteria, "improvement" becomes subjective. Teams waste time debating interpretations rather than executing.
SMART Solution: "Increase primary CTA click-through rate from 12% to 15% within 6 weeks via UI refinements validated through A/B testing"

3. Loss of connection with business goals
Problem Example: "Redesign admin dashboard with new analytics widgets" (while cart abandonment hits 65%)
Why It Fails: Teams often optimize what's measurable rather than what matters. Internal-facing "improvements" frequently divert resources from core user needs.
SMART Solution: "Reduce cart abandonment by 25% in Q2 through streamlined checkout and exit-intent promotions"

The Golden Rule:effective SMART goals answer three questions:

Clear - Does everyone understand exactly what to do?
Valuable - Will this actually move key metrics?
Timely - Is this the most impactful use of resources now?

By pressure-testing goals against these criteria, teams avoid busywork and focus on what truly drives product success.

SMART Goals for Product Managers

A product manager (PM) guides the product in the right direction by clearly defining priorities. SMART goals help PMs clearly formulate priorities for themselves and their teams.

Individual Goals
Example: “Conduct 10 interviews with key customers by the end of the month and prepare 2 hypotheses for testing.” This type of goal develops Product Discovery skills and keeps the focus on real user needs.

Team Goals
Example: “Increase Retention from 20% to 30% per quarter by improving onboarding processes.” Here, it is important that the goal is aligned with development, design, and is based on data.

Quarterly or Annual Goals
SMART goals also work well over longer distances. For example:
“Launch a new version of the product in three countries with at least 35% user retention during the first two weeks of use by the end of Q3.”

For PMs, SMART isn’t only about task control, but also about shaping a logical, strategic approach to product development aligned with business goals.

SMART and Agile teams

Agile implies flexibility, but flexibility does not mean a lack of structure. SMART goals fit perfectly into the agile approach, especially if they are properly integrated into sprints.

In sprint planning, you can use SMART as a basis for user stories and tasks. For example: "Increase the filter response speed on mobile devices to <1 second in 2 sprints."

During retrospectives, reviewing SMART goals helps evaluate what worked and what did not. This gives food for reflection and helps avoid repeating mistakes.

Tools like Jira, ClickUp, and Notion are excellent for recording and tracking SMART goals. The main thing is not to make them visible and regularly discussed during planning, demos, and retros.

Agile and SMART complement each other by making teams predictable without creating unnecessary processes.

How to Implement SMART in a Development Team

Setting goals is half the battle. The main thing is to make sure that the entire product development team embraces this approach as part of their daily workflow.

Training and Workshops

Not everyone in the team immediately understands why SMART is important and how to apply it. It is useful to conduct short workshops where the difference between a “vague” and a “smart” goal is demonstrated using real tasks. It is good to introduce quick exercises, where each team member sets 1–2 SMART goals relevant to their roles.

Templates and examples

People are willing to repeat if there is an easy-to-use structure. Templates in Notion or Google Docs, structured clearly with fields such as "What are we doing?", "Why?", "How do we measure success?", and "When will we complete it?", lower the entry barrier, clarify expectations, and build good habits.

Handling Objections

Occasional pushback—"We already manage fine, why use SMART?"—is common. Highlight that SMART is not about bureaucracy but clarity and efficiency, saving time and reducing stress by clearly tracking progress instead of merely "doing tasks."

Tools and Templates for SMART Goals

To successfully embed SMART goals into your workflow, you'll need more than just understanding—you need the right tools.

Tables (Excel, Google Sheets)

This is a classic — simple, clear, accessible to everyone. You can create tabs by sprints, teams, or people, and use color coding of progress. Important: keep the table alive, not abandoned.

Notion and ClickUp

Great for structured work. You can create a task template with fields: Specific, Measurable, Achievable, and so on. Notion is also convenient for visualizing progress, for example, through dashboards.

Plugins and Project Management Tools

For Jira, Trello, Asana, and other planners, some plugins and extensions add SMART support. Some allow you to set goals and immediately link them to tasks, which makes it easier to track in real time.

While tool choice depends on team maturity, the core requirements remain constant: goals must be visible, accessible, and regularly updated. Without these elements, even the best intentions get lost in daily operations.

How to Evaluate and Adapt SMART Goals

Even perfectly crafted SMART goals can become outdated. That's why continuous evaluation is just as crucial as initial goal-setting, especially in dynamic product environments.

Review cycle: month, quarter

Regular reviews (monthly or quarterly) are critical, particularly for agile teams where priorities frequently shift. Embrace goal revision as a pathway to success rather than stubbornly adhering to outdated objectives.

Visualization of progress

Clear visual progress tracking — dashboards, graphs, or simple traffic light indicators (red, yellow, green) — in tools like Notion or ClickUp boosts team motivation and ensures goals remain front-and-center rather than forgotten in documents.

This approach turns SMART goals from static targets into living guides for your product's evolution.

Conclusion: Why Product Teams Need SMART

Clear goals accelerate product growth; vague ones lead to stagnation. Without well-defined objectives, teams flounder, metrics plateau, and users lose faith in progress.

The SMART framework transforms this dynamic by helping digital teams:

Focus on what is important.
Clarify and measure work effectively.
Track progress and celebrate achievements.
Avoid burnout and chaotic decisions.
Increase productivity not through clarity, not extra hours.

For teams new to SMART goals, start small:

Set one SMART goal for a sprint.
Test simple templates in daily standups.
Review outcomes during retrospectives.

The key is simply to start. The measurable improvements in alignment, progress, and results will clearly demonstrate SMART’s value.

Author: Andrey Stepanov, CTO at Byteminds

Building Teams for Digital Products: Essential Roles, Methods, and Real-World Advice

Byteminds Agency — Wed, 11 Jun 2025 10:46:06 +0000

A digital product is more than just a set of features or an interface. Creating it is a process that demands not only technical expertise but also effective team organization.

Product development involves high uncertainty at every stage, requiring each team member to mitigate risks and adapt to change actively.
In this article, we’ll explore:

The essential roles in digital product development
The pros and cons of working with freelancers, outsourcing, and in-house teams
How to choose the right collaboration model for your project

Why Product Development Isn’t About Websites

Website or landing page development follows a predictable path: predefined layouts, structured pages, and minimal uncertainty. Products, however, are dynamic and continuously evolving. At every stage, new questions arise, like, “What’s more important: refining the interface or quickly releasing a new feature?” forcing teams to pivot tasks and strategies.

This is why product development teams differ significantly: they require more than just a group of specialists. They need an ecosystem designed to handle constant change.

Yet in practice, many fail to grasp this difference or even see its necessity.

This “design-first, develop-fast” mindset is common but fundamentally flawed for product development.

Now that we’ve set the stage, let’s delve into the nuances of team collaboration models.

Key Roles in a Product Team

For a digital product to progress rather than stall indefinitely, each role must own its responsibilities and actively reduce uncertainty.

Below, we break down the core roles that drive progress.

Product Owner: The Strategic Navigator

The Product Owner (PO) ensures business objectives aren’t lost in endless refinements. This role demands deep market understanding, the ability to prioritize team ideas, and the judgment to decide what’s essential now and what can wait.

For instance, if developers propose a complex feature, the PO assesses: Will this actually deliver business value?

Their expertise should span:

The product’s core purpose and its competitive landscape
Market-specific constraints and opportunities
Audience pain points and unmet needs

These insights help the Product Owner develop meaningful hypotheses and make informed decisions.

Important: Often, the PO is the client or a stakeholder with market expertise. Their role is to minimize strategic uncertainty by setting priorities and focusing on valuable solutions. Decisiveness here is crucial—without it, the risk of developing irrelevant solutions is high.

Product Producer: Bridging Strategy and Execution

Far more than just a project manager, the Product Producer acts as the critical link between business goals and technical execution. They reduce chaos, manage client expectations, and shield the team from unnecessary scope changes.

If a business demands a complex feature that developers estimate will take months, the Producer finds a compromise, like delivering an MVP sooner or suggesting an alternative solution.

Beyond task decomposition and timeline management, the Producer understands business priorities deeply. This additional insight helps him make better decisions during the product development process.

The Product Producer is an enhanced version of a project manager and the right-hand to the Product Owner. They organize tasks, establish transparent processes, and build predictable workflows.

Critical Note: If the Product Owner hasn't adequately prioritized tasks, the Producer can partially mitigate this, but can’t fully replace the strategic vision of the Product Owner.

Business Analyst: Architect of Cohesive Systems

The Business Analyst’s main role is to serve as the vital bridge between conceptual requirements and practical implementation. Their core mission is to ensure that all product requirements:

Are technically feasible and internally consistent
Contribute to a unified system architecture
Account for critical edge cases and real-world usage scenarios

By thoroughly understanding how different system components interact (or should interact), the Analyst transforms abstract ideas into clear, actionable tasks for the development team. Their technical discernment helps identify whether a proposed feature provides genuine value or simply becomes unnecessary complexity — what we might call "attaching a fifth wheel to a car."

Key Impact: The Analyst helps the team navigate ambiguous requirements, highlight key aspects, and focus on the main thing, reducing tactical uncertainty.

UX Designer: Crafting Intuitive Experiences

Far more than just creating visually appealing interfaces, the UX Designer engineers user journeys that are:

Intuitively navigable
Purposefully structured
Optimized for the target audience

For mass-market products, this means prioritizing simplicity and accessibility above all. The designer's prototypes and wireframes serve as the blueprint for how real users will interact with and derive value from the product.

Superior UX design minimizes two critical risks:

User frustration caused by confusing interfaces
Lost conversions due to poor experience design

By establishing predictable, user-friendly interaction patterns, the UX Designer ensures customers can effortlessly achieve their goals within the system, without getting lost or discouraged.

Team Lead: Guardian of Technical Excellence

A skilled development team alone isn't enough — without technical leadership, projects can quickly derail.

The Team Lead serves as the architectural cornerstone, ensuring:

Robust system design that withstands growth
Consistent engineering practices across the team
Production-ready code quality
Scalability planning from day one

Without this role, teams risk creating disposable solutions that crumble under real-world loads. The Team Lead reduces technical uncertainty by making informed architectural choices, ensuring code quality, selecting appropriate tools, assigning tasks based on developer skills, and implementing rigorous testing.

Have you heard of the Three Amigos principle? It’s a collaborative communication method where requirements, potential scenarios, and risks are discussed jointly beforehand. This significantly reduces misunderstandings and increases product quality.

So, one of the three amigos will often be the Team Leader, who dives into the product before the start of development to properly reduce technical uncertainty during further work.

Development Team: Execution Powerhouse

Comprising developers and QA specialists, this group executes tasks, writes code, tests, and implements features.

Crucially, they must collaborate effectively with other roles rather than merely follow instructions. Their clear task execution, adaptability to change, and attention to detail significantly reduce project uncertainty.

Building Your Product Team: Choosing the Right Approach

Creating a successful digital product requires more than just talent—it demands the right team structure. You essentially have three options: hiring freelancers, partnering with an outsourcing firm, or building an in-house team. Each approach has its trade-offs, and the best choice depends on your project’s needs, budget, and long-term goals.

Freelancers: Cheap, Flexible, and Fragmented

At first glance, freelancers seem appealing: they’re cost-effective, available on demand, and can handle specific tasks. But assembling a full product team from freelancers is often a recipe for frustration. While they excel at executing well-defined assignments, they rarely engage deeply with the product vision or collaborate effectively with others.

The core issue isn’t skill—it’s alignment. Freelancers work transactionally, not strategically. Without strong product management on your side, coordination can quickly become chaotic. Deadlines slip, communication falters, and what should be a cohesive product often ends up as a patchwork of disjointed solutions.

When it works: For one-off, short-term tasks, but not for building an entire product.

Outsourcing: Speed, Expertise, and Lower Risk

Outsourcing strikes a balance between flexibility and structure. A competent agency handles everything from scoping to execution — ideal if you lack the time, resources, or expertise to manage development internally. Even if you already have an in-house team, outsourcing can accelerate your MVP launch by offering fresh perspectives and avoiding internal bottlenecks.

Key advantages:

Faster execution – experienced teams avoid common pitfalls
Established processes – they deliver structured, scalable solutions
Lower risk – if the project fails, costs are contained; if it succeeds, you can transition it in-house

The catch? Choosing the right partner. Vet their portfolio, clarify expectations upfront, and ensure contractual alignment on goals.

In-House Teams: Commitment at a Cost

A dedicated internal team is the gold standard for long-term product development. Your employees live and breathe the product, adapt quickly to change, and drive sustained innovation. The catch? It’s expensive and demanding.

Building an in-house team means:

High recruitment stakes – finding skilled people who align with your vision takes time
Ongoing investment – salaries, training, and culture-building aren’t one-time efforts
Process overhead – you’ll need strong leadership to maintain cohesion and productivity
Mistakes are costly – mis-hires or poor management can derail progress entirely.

But when done right, an in-house team becomes your greatest competitive edge.

The Bottom Line:

Freelancers - only for discrete tasks
Outsourcing - ideal for MVPs and resource-strapped teams
In-house - the best choice—if you can sustain it

Your team structure isn’t just about talent—it’s about how well that talent works together. Choose wisely.

The Art of Effective Teamwork: Principles That Drive Success

Building a high-performing product team isn’t about rigid processes or perfect plans—it’s about fostering the right kind of collaboration. Here’s what truly makes teams work.

Communication is one of the few points that consistently drives results. But effective communication isn’t about weekly reports or ritual demos—it’s about active dialogue. Teams need space to debate ideas, challenge assumptions, and co-create solutions. Still, there’s a fine line between productive discussion and wasted time.

We’ve found that structured collaboration prevents misalignment. The magic happens when both sides engage authentically — not as "client and contractor," but as partners willing to listen, adapt, and occasionally compromise.

It’s also critically important to understand who is responsible for what. Simply assigning roles is not enough — each team member needs to perform effectively within their area and avoid overstepping into others’ domains.

Clear roles matter, but boundaries matter more. Consider this cautionary tale:

A Product Producer skips stakeholder conversations and relies solely on metrics → surfaces flawed insights
The Analyst wastes time untangling those assumptions instead of focusing on discovery
The UX Designer, lacking direction, makes arbitrary interface changes
The Team Lead gets dragged into priority debates instead of safeguarding the architecture
Developers juggle conflicting tasks, creating technical debt

The result? Escalating uncertainty and operational chaos. True ownership means excelling in your role while trusting others to do the same.

The next important thing is the project plan. A good project plan is a compass, not shackles. Products change, and that’s normal. The ability to adapt quickly is what makes teams resilient. Flexibility, however, doesn’t mean disorder: a shared direction helps teams pivot while staying aligned.

And finally — people. They are the most valuable asset in any project. Invest in them. Your team’s growth directly impacts your product’s quality. When you provide learning opportunities, encourage professional development, and create psychological safety, you don’t just get employees — you get invested partners who bring their best thinking to tough challenges.

The difference between good and exceptional work rarely comes down to process. It comes down to how your team engages — with the product and with each other.

Author: Andrey Stepanov, CTO at ByteMinds

Goals in Digital Development: How to Launch a Digital Product Without Failure

Byteminds Agency — Thu, 29 May 2025 10:23:41 +0000

The Client Knows What They Want, but That’s Not Enough

When clients approach a development team, they’ve often already put significant thought into their vision. They have a clear mental image of the final product, and sometimes even clear goals and success metrics. These ideas typically translate into functional requirements, such as:

"The product should include a supplier account with X and Y capabilities."

"We need an app where users can apply for banking products."

At first glance, this "shopping list" of features might suggest the client has everything figured out, leading the development team to take the requirements at face value. So the team might follow these requirements literally. After all, isn’t the client the expert in their own business?

However, if the development team doesn’t engage in deeper discussions about these requests, their role risks being reduced to mere task execution: "Build what you’re told, exactly as specified." In such cases, the team becomes a group of passive performers rather than strategic partners. As a result, a product is created that "works according to the technical specifications," but does not necessarily help the business.

A truly high-performing development team doesn’t just complete tasks — it works to achieve product goals. To foster this mindset, we immerse the team in the product’s strategic vision from day one. By understanding the bigger picture and the hypotheses behind decisions, they don’t just build features — they generate ideas for improving the product. This is what separates a team of implementers from a team of creators.

Why Goals Matter More Than Feature Lists

Focus on the result, not on the tasks

Consider a banking service project. You could instruct the team: “Build a loan calculator.” Or, you could frame the goal: “Double the completion rate of application forms.”

The first approach limits the team to checking boxes, delivering a functional but uninspired solution. The second empowers them to ask critical questions: Should the calculator be embedded earlier in the user journey? Could automated pre-filling boost conversions? Suddenly, the team isn’t just coding; they’re problem-solving. The difference in engagement and impact is monumental.

Priorities are determined by goals

In every development cycle, there comes a point when it becomes clear: not everything will be completed on time. Without clear goals, tasks risk becoming arbitrary or worse, irrelevant. Chaos begins: what to postpone, and what to do right now? Someone decides this based on intuition, but this is poor validation. Goals and metrics are necessary to identify what truly matters. Without objective criteria, decisions default to gut feelings or competing opinions. Stakeholders push for their "must-have" features, but without alignment, "must-have" means different things to everyone.

Formalized goals change the game. They act as a filter, separating what truly drives success from what’s merely noise. It is easier to decide which tasks are critical for achieving success and which can be postponed or removed altogether.

Shared Goals = Shared Responsibility

When teams work without clear goals, responsibility falls solely on the client. The client dictates requirements; developers merely execute. But when goals are explicit and understood, the dynamic shifts. The team transitions from passive implementers to active partners. They propose solutions and challenge assumptions — because they’re invested in outcomes, not just deliverables. Responsibility for success is shared, and this is the key to a strong and motivated team and, subsequently, a successful product.

From Feature Requests to Strategic Goals

The foundation of effective goal-setting lies in the SMART framework – a goal should be Specific, Measurable, Achievable, Relevant, and Time-bound. SMART goals aren't always attainable. So, let's examine how vague requests can be reframed into actionable, results-driven goals.

Example 1.

Banking: From Basic Functionality to Active Engagement
Product: Mobile banking application
Client Request: "We need an app for users to manage accounts and loans."
Result: A typical “shopping list”. The dev team builds what was asked, but months later, analytics show: the app isn’t driving growth.

Goal-Driven Alternative: Increase the share of active users by 20% within six months.

With this clarity, the team prioritizes:

Intuitive UI/UX design
Automated payment reminders
Reward systems (e.g., cashback for app usage)

Example 2.

Education: Completion Rates Over Feature Checklists
Product: Online learning platform
Client Request: "Build a platform with video lessons, tests, and certificates."
Result: Platform built as requested, but most learners drop out halfway.

Goal-Driven Solution: Achieve a 70% course completion rate.

This shifts focus to:

Gamification elements (badges, progress tracking)
Personalized email nudges
Interactive support features

Example 3.

E-Commerce: Converting Browsers to Buyers
Product: Online store
Client Request: "Implement filters, shopping cart, and checkout."
Result: Requirements are met, but traffic doesn’t translate into sales.

Goal-Driven Approach: Boost conversion rates by 15%.

The team focuses on:

User journey optimization
Smart product recommendations
Streamlined checkout process

How to Set Effective Goals: Tools and Frameworks

Understanding why goals matter is just the beginning. Now let's explore how to craft them effectively using these proven tools:

1. Problem Understanding (PU) Framework

This is a basic but crucial tool. Helps clarify the roots of client requests and align on expectations before jumping to solutions:

Clarifying the origin of their vision
Identifying core needs behind feature requests
Establishing common ground before proposing solutions

2. Impact Mapping

This tool links business goals and product functions. It helps to highlight which tasks are really important for achieving goals and which can be postponed. The influence map works great when the client already has a general understanding of what needs to be done.

Pro tip: Use it to identify priorities, spot redundancies, and avoid “solution jumping” (building before understanding).

3. Hypothesis Mapping

For ambiguous or innovative projects. Helps teams explore what users might need, test assumptions, and tie features to real value.

When direction is unclear, this approach:

Structures assumptions about user needs
Validates ideas through measurable experiments
Shifts focus from features to real user value

Unlike impact mapping (business-focused), hypothesis mapping centers on user experience validation.

The Goal-Setting Playbook

Follow this step-by-step approach:

Anchor to Business Objectives
Identify the main business goal: revenue growth, customer retention, market expansion.

Quantify Success
Break broad objectives into KPIs. For example:

"Increase premium conversions by 30%"
"Reduce churn to under 5% monthly"

Build Your Impact Map

Link metrics to tasks via an impact map.

Generate Solutions
Use a hypothesis map to find creative solutions:

Test innovative approaches
Validate with user feedback
Iterate based on data

Remember: Goals aren't static. Revisit and refine them as you gather insights from real user behavior and market response.

Conclusion: Laying the Right Foundation for Success

Understand the product’s purpose, define success metrics, and apply the right tools to stay focused and effective. Record goals, check their relevance, and use tools like the impact map and hypothesis map.

This disciplined approach doesn't just improve success rates—it transforms development from a mechanical process into a purposeful journey.

Remember: With well-set goals, half the work is already done — the rest becomes clearer, more focused, and more meaningful.

Author: Andrey Stepanov, CTO at ByteMinds

How to Become a Kentico MVP - Interview with Kentico MVP Dmitry Bastron

Byteminds Agency — Thu, 27 Mar 2025 11:52:27 +0000

Dmitry Bastron is the Head of Development at ByteMinds and has been working with Kentico since 2016. In 2020, he earned the title of Kentico MVP — a recognition awarded to the most active and valuable members of the Kentico community.

In this interview, Dmitry shares how his journey with Kentico began, what motivated him to become an MVP, and what it takes to earn the badge yourself.

How Did Your Journey with Kentico and the MVP Program Begin?

To start with, Kentico was the first CMS I ever worked with. When I joined ByteMinds, I was working with various platforms, building up my experience and skills to eventually become a senior developer. Throughout this journey, I received tremendous support and knowledge from the Kentico community.

Early on, when I was still new to Kentico, I often visited https://devnet.kentico.com, specifically the Questions and Answers section. That’s where my journey with Kentico really began. Whenever I didn’t understand something, I would post my questions and always received helpful answers.

Over time, I noticed the most active members of the community — people who regularly helped others — and I came to respect them for their contributions. Some of them were Kentico MVPs, although at the time, I didn’t fully understand what that meant.

As I gained more experience, I realized I had a lot of knowledge to share. That's when I decided I wanted to become a full-fledged part of the Kentico community because it had played such an important role in my growth as a developer. I started answering questions and became an active contributor.

Eventually, my activity was noticed by Kentico, and, in 2019, they invited me to join the MVP program. And I thought, why not? Back then, there weren’t many specific requirements — just a general expectation to stay active throughout the year by writing articles, answering community questions, and helping promote Kentico more broadly. In 2020, I officially became a Kentico MVP and have renewed the title every year since.

Why Become a Kentico MVP? What Motivated You?

When I began my path toward MVP, one of the main benefits —as highlighted by Kentico themselves—was the opportunity to connect with other top professionals and exchange knowledge. And that truly is a great perk. But for me, it wasn’t the main reason.

What really attracted me was the chance to engage directly with the product team, offer feedback, and influence the development of the Kentico itself. That was the deciding factor —and to some extent, it worked out! I’ve been able to share my ideas with the developers, and some of that feedback has positively impacted the product.

Another strong motivator was the annual MVP Summit. It’s an event where all MVPs gather at Kentico’s office to meet the architects and product team face to face. It’s a great chance to participate in sessions, network in person, and have some fun together. As an extrovert, this kind of environment was especially appealing to me and played a big role in my decision to join the MVP circle.

Is It Hard to Become a Kentico Developer? What Background Do You Need?

I’d say the entry barrier isn’t very high. One major advantage of Kentico is its excellent documentation and developer guides, which make onboarding fast and smooth.

Of course, there’s still a basic level of knowledge required. At the very least, you should have a general understanding of web development. Experience with other CMS platforms is helpful, but not mandatory. As a first CMS, Kentico leaves a great impression, and the learning curve is quite friendly.

What Do Kentico MVPs Do and Why Are They Important?

Firstly, any mid-sized or large-scale product needs an active community to help reduce the load on customer support. When users enjoy working with a product, they will naturally start sharing their experiences, helping others, and contributing to the product’s success. Kentico is no exception — it has a strong and engaged community of users and developers.

Within a community, there are always a few people who stand out through their consistent involvement. That’s how the Kentico MVP group is formed: it's made up of those particularly active contributors who go above and beyond to support others and help the community grow.

The other important and equally valuable aspect of the MVP program, which Kentico highly appreciates, is the opportunity to get feedback on how the product is being used —especially from Kentico itself.

Since CMS developers don’t typically build websites using their own CMS, this creates a challenge: it’s difficult for them to assess how well and effectively their product works in real-world scenarios. They need an external perspective — ideally from two angles: the user’s experience (how intuitive the interface is, how easy it is to perform daily tasks) and whether the CMS meets technical needs (performance, flexibility, feature sets, etc.).

For a long time, the Kentico MVP program focused only on technical experts. But recently Marketing MVPs have been introduced — people without a technical background but with expertise in marketing. Their perspective is extremely valuable. While technical experts focus on improving the platform from a technical standpoint, they sometimes overlook a key element: the real-world importance and impact of those features. This is where Marketing MVPs shine. They can articulate why a specific feature matters, what it enables users to achieve, and how it contributes to the success of a site or product. They help explain the "why" behind the "what."

This year brought changes to the community program. In addition to MVPs, Kentico has introduced a new title: Community Leader. While this role carries fewer benefits, it serves to recognize individuals who are more focused on growing and supporting the community itself rather than directly contributing to product development. Kentico wants its community to grow, thrive, and become more visible — and this is a great first step for anyone aiming to eventually become an MVP.

How Much Time and Effort Does It Take to Become a Kentio MVP? What Actions Are Required?

Applications are typically accepted at the beginning of December, so if you're aiming to become an MVP, you’ll need to stay active throughout the year. Consistent engagement is a key requirement.

But no one will track your activity for you. If you're interested in becoming a Kentico MVP, your first step should be to contact Sean Wright, who currently manages the MVP program. He can help you find the right mix of activities that will boost your chances of selection.

So, what types of activities does Kentico expect? Primarily, you’ll need to focus on promoting Kentico and actively engaging with the community. This might include:

Writing blog posts on various topics about Kentico features or your experience using the platform. These don’t have to be glowing reviews, just honest and practical experiences.
Speaking at conferences, whether they are tech-focused or broader in scope, where you can include Kentico in your presentations.
Developing and publishing modules or extensions that improve day-to-day experience for developers, content editors, or marketers using Kentico.

Helping others in the community is also valuable. However, if this is your sole focus, the Community Leader title may be a better fit for you.

The best way to start is by trying out different types of contributions and finding what you enjoy. Most importantly, your efforts should come from genuine interest and passion. The MVP program welcomes a wide range of contributions—there’s space for everyone.

Are There Benefits of Being a Kentico MVP?

One of the best perks of MVP status is participation in the annual Kentico Connection conference. If you present a session, you get a free ticket. MVPs also receive early access to upcoming features, get insider knowledge about Kentico's roadmap, and join regular calls with the MVP team.

This early insight can be incredibly helpful for your work, as it allows you to plan ahead and adapt your projects accordingly. You become more valuable to your agency because you're staying ahead of the curve.

You can find out a full list of MVP benefits in Sean's post here: https://community.kentico.com/blog/you-could-be-a-kentico-mvp

How Popular Is the Kentico Platform, and What Are the Career Prospects for Kentico Professionals?

Kentico’s popularity is moderate but growing. More and more businesses are transitioning to Xperience by Kentico (XbyK) and the product team is making impressive progress— releasing new features monthly and continuously enhancing the platform. It looks like a promising product with a bright future.

Any Personal Advice for Those Interested in Working with Kentico and Becoming an MVP?

The MVP community is a fantastic group of people. I genuinely enjoy interacting with them — many have become personal friends. They’re smart, driven, and passionate professionals, making it a great space to exchange ideas and grow.

In some larger platforms, the MVP programs include dozens or even hundreds of members, which can make it harder to form real connections. At Kentico, there are only 15 MVPs this year. That’s big enough for diversity, but small enough to feel like a close-knit family.

And with that, I want to once again congratulate all of this year's Kentico MVPs. They’re an incredible group of professionals — dedicated, passionate, and genuinely supportive of both the product and the community.

They absolutely deserve the recognition, and it's a pleasure to work alongside them:

Liam Goldfinch
Ben Quinlan
Elmar Höfinghoff
Michael Eustace
Trevor Fayas
Andy Thompson
Derek Barka
Mike Wills
Wesley McChristian
Joe Peschardt
Brian McKeiver
Jeroen Fürst
Dmitry Bastron
Roel Kuik
Łukasz Skowroński

Author: Dmitry Bastron, Head of Development at ByteMinds / Kentico MVP

How can a team lead figure out a new project when nothing is clear?

Byteminds Agency — Tue, 04 Mar 2025 10:42:28 +0000

Hello! My name is Maria, and I am a team lead and backend developer at ByteMinds. Life as a team lead would be easier if every new project started from scratch. But the reality is different: you often have to take on someone else's code, understand the old architecture, catch the elusive context, and organize chaos.

It becomes even more difficult when a project is handed over from another team – especially when documentation is fragmented, decisions are unclear, and dependencies are not obvious. So, how can you quickly get up to speed, avoid getting lost in uncertainty, and organize the process in a way that helps the team work productively?

In this article, I will share my experience: I’ll explain how to understand a complex project, establish processes, and make it feel like "your own".

How not to drown in a new project

Every new project comes with some (or a lot of) stress. But it becomes manageable if you know which strings to pull. Here are a few steps that can help:

Set the vector: why are we doing this? Understand why your project exists in the first place. Sales? Improving UX? Adding new functionality? A team lead cannot be effective if they don’t understand the end goal. Start by talking to the business or client to identify key success indicators, and then try to mentally” align these goals with your work. Clarify the main user scenarios.

Draw a map: architecture under a magnifying glass. You should have a clear diagram of how all the system components interact. Which services interact with which systems? What is data stored? Study the documentation if it exists; if it doesn’t, start gathering it yourself. Make sure that every team member has access to up-to-date information. Validate the existing data: work with the current team and the client to ensure that the data is still relevant and usable.

At the onboarding stage, you don't need to go into implementation details. You just need to understand how current the documentation is, how to set up the project, and what integrations, logging, and monitoring are in place. Pay special attention to sections where you’re unsure how to approach them.

Remove chaos: the access matrix. When a project involves many people and systems, access chaos is the first thing that needs to be sorted out. Create an access matrix: specify who should have access to which systems and who should not. This table will be a lifesaver when onboarding new employees and will save time. Simply walk new employees through the access matrix and quickly reach out to the client if any permissions are missing.

Handovers: secrets to successful knowledge transfer

Handovers are sessions where the "old hands" of the project pass on essential knowledge to newcomers. Many people treat them as formalities, but that’s a huge mistake.

Focus: topic-specific sessions. Break handovers into distinct topics: architecture, deployment, QA, etc. This allows for better focus and preparation. Before each meeting, review any available documentation on the topic and prepare questions. Be sure to share these questions with the participants in advance to avoid wasting time on unnecessary discussions.

Ask uncomfortable questions. Inquire about typical mistakes the old team made. What are the most difficult aspects of the project? Are there important, non-obvious features that aren’t documented anywhere? What information is missing if you need to upload changes or run tests tomorrow? You can collect these questions in advance and send them to the client before the call – this will make the conversation more meaningful and allow everyone to focus on the essentials.

Don't lose information: record meetings. Record all handovers and keep the recordings publicly accessible. This will be useful if a new team member wants to quickly get up to speed. Even months later, you can refer back to these recordings to recall details. New team members can simply review the recordings instead of bombarding more experienced colleagues with endless questions in the chat.

Plan wisely: tasks and priorities

How can you distribute tasks to make sure everything important gets done, without wasting resources? The keys are planning and auditing.

Understand the backlog. Review the current backlog. Which tasks are critical? Which ones can be postponed? For example, if you know the project will be redesigned in a year, then working on architectural updates may be unnecessary. Prioritize tasks based on the overall goals of the project.

Conduct an audit: this is your insurance. Even if the client doesn’t require an audit, do it for yourself. Evaluate the architecture, integrations, and technical debt. This will help identify weak points of the system and serve as your safety net if something goes wrong.

An audit helps you define the risks and limitations early on. If a client suddenly needs an implementation that the system cannot support, you’ll always have something to show them. The biggest challenge here is usually the “blank slate” problem – you don’t know how much time it will take or what should be done first. You can dig through the code endlessly, but there’s no point in doing so. Focus on key priorities. For example, look only at the issues to the current backlog and the feature closest to implementation.

Sometimes you need to reassess an estimate – and this shouldn’t seem strange to you, the team, or the client. There are situations of uncertainty where it feels like the estimate might be way off. In such cases, make an estimate for research, not implementation. Clients will have realistic expectations – they’ll know what you are currently working on. Developers won’t be tied to false estimates, meaning they won’t have to work late or disappoint the client with incomplete tasks.

Experiment with Proof of Concept (PoC). If you’re unsure whether the chosen approach will work, create a PoC. This is a small-scale experiment to test if your idea will work. The key here is not to get bogged down in the details. Remember, the goal of PoC is to determine whether the idea can be implemented, not to produce a finished product.

Deployment without stress: setting up releases

Managing releases is another key aspect of a team lead’s role. Not everything that sounds simple turns out to be so in practice.

Automate where possible. Find out how the project pipelines are set up. Are there fully automated processes? If not, figure out which stages require manual intervention and work to optimize them.

Agree on release windows. Before each release, notify all stakeholders: the team, the client, and the users. Define fixed time windows for applying changes to minimize risks.

Always have a plan B. Keep a rollback plan somewhere "under your pillow". If a release causes problems, who will fix them and how? Create a step-by-step checklist for handling such situations.

Difficulties are opportunities for growth

The role of a team leader is a balance between technology, people, and processes. The key is not to fear uncertainty. A systematic approach, open communication, and attention to detail will help you overcome any challenges. Don’t forget: the team leader is the one who leads.

Author: Maria Serebrovskaya - Team Lead at Byteminds