Frequently Asked Questions

DAX for beginners is best started with the basic aggregation functions SUM, AVERAGE and COUNT, then DIVIDE and CALCULATE, and after that the time intelligence functions. Classic period-based calculations also require a separate date table that is created and configured correctly.

Copilot in Power BI is Microsoft's AI assistant that creates and edits reports, generates summaries, answers questions about your data and helps with DAX. The quality of the output depends on the Power BI semantic model.

The user describes the result they need in plain text, and Copilot for report creation picks the relevant data and builds a page with visuals. The result can be edited manually or refined with follow-up prompts.

Copilot in Microsoft Fabric helps generate and explain code, build queries, work with data processing pipelines, analyse information and prepare reports. As of 2026, some of these capabilities are still in preview.

No. Copilot automates part of the routine work, but the analyst still defines the business logic, builds the data model and verifies calculations and conclusions.

Microsoft Copilot Power BI depends on the quality of the model and the data, and it can return inaccurate answers. Critical calculations need to be verified, and at scale you also have to account for Fabric capacity consumption.

Yes. Standard use of Copilot requires a paid Microsoft Fabric capacity from F2 or a Power BI Premium capacity from P1, plus approval from your administrator. Microsoft also offers a separate Fabric Copilot capacity, so it is worth checking the licensing model for your own infrastructure before switching it on.

Custom development makes sense where there is unique logic, specific integrations, or requirements that no off-the-shelf product can cover without significant compromises.

If the task can be solved with an existing tool that covers 80% of the needs — we will say so right at the start. But if the business has already outgrown template solutions or is building something non-standard, custom development gives full control: logic, roles, integrations, reports — everything tailored to your specific requirements.

A ready-made platform is a quick start within the limits of what it was designed for. As long as the business fits within those limits, everything works. But when non-standard processes, specific logic, or the need for deep integrations appear, you end up with workarounds, plugins, and constant limitations.

A custom solution is built around you: it scales together with the business, integrates with any services, and does not depend on a third-party platform's decisions about API or policy changes.

Mostly these are either tools for a company's internal operations or products used by clients and partners. The first group includes management systems, accounting platforms, and integration solutions connecting existing services. The second — web and mobile applications, partner portals, and e-commerce. Often one is intertwined with the other: for example, a distributor platform connected internally to ERP and analytics. The specific set always depends on which process needs to be solved.

It depends on complexity and scope. Sometimes an MVP can be assembled in a month, while a full system takes several months. If deep integration or complex analytics built from scratch is required, the timeline is longer. Development is always broken into phases, and the first results appear before the project is fully completed.

We start with the Discovery phase. Here we work together to clarify the real task, the constraints, and the criteria for success. This is the point where we verify that the task is correctly formulated before we start solving it.

Then development moves in iterations, with a concrete result in each phase. You review reports, give feedback, and the next stage takes your comments into account. This way, the solution is built step by step, and you have the opportunity to influence it along the way.

Daily immersion is not required, but complete detachment will not work either. At the start, it is important to properly hand over the context and answer key questions. After that, you occasionally need to make decisions on priorities, review demos and reports, and give feedback. The clearer the communication at each stage, the fewer revisions and misunderstandings at the end.

Every project has a dedicated manager who is responsible for communication with the team, deadlines, coordination, and client updates. You communicate with one person who knows the state of the project better than anyone. We choose the methodology based on the specific context: Scrum, Kanban, or a hybrid if you already have your own internal processes that we need to adapt to.

With T&M, new priorities simply fit into the next cycle. With a fixed budget it is more complicated, but still manageable: we sit down, look at the current scope, and decide what is more important to do now and what can be postponed. The key point is that no decision is made without your involvement. Everything is transparent, and you always know what changed and why.

A QA engineer works within the same team and gets involved with every feature. Manual testing covers scenarios where logic and user experience matter. Automation is added where the same things need to be checked regularly, without errors caused by the human factor.

We separately test load, security, and edge cases. Before release, the client goes through final acceptance testing on the live system. This is a full verification of what is about to be launched.

In backend development we work with PHP (Phalcon, Yii2), Java, and Symfony; for integrations — REST API and GraphQL. We most often build the frontend with Vue.js, use PIMCore for content management, and Swift and Kotlin for mobile solutions. All of this has been used in real projects for retail, e-commerce, the public sector, media, and manufacturing.

The stack is always chosen for the task. In one project, performance is the priority; in another, integration flexibility; in a third, scalability. And we always explain to the client why we propose this particular set of tools.

We have connected products to CRM, ERP, warehouse systems, marketing platforms, payment gateways, email services, government APIs, and marketplaces. If a system has an open API, we connect directly. If not, we find another way: parsers, proxies, custom connectors. What matters is that the result works in a real operational environment.

The code, documentation, and infrastructure are fully transferred to you after payment. We hand everything over to your Git or any other system of your choice. No closed modules or hidden dependencies that would tie you to us. If you want to change vendors or develop the product with your own team — there are no obstacles.

The code goes through several levels of review, manual or automated testing, and performance and security checks. But an even more important factor is the design stage. If a feature is poorly thought out or logically contradicts the rest of the system, it does not make it into development. Fixing architectural decisions after release is far more expensive than asking the right questions at the start.