The problem is that good code alone cannot save a project. A successful development partnership requires shared understanding, clear communication, and mutual accountability.

In this article, we’ll provide a step-by-step guide on how to find a software development partner that meets all your requirements, supports your values, and can help build a business that lasts.

1. Define What You Need

Before you start browsing portfolios or jumping on introductory calls, take some time to define your project goal. Are you testing an idea with a quick prototype? Creating an MVP to attract investors? Or scaling a full-fledged product that needs ongoing support?

Each of these stages requires a different type of team. Some vendors specialize in fast, experimental builds. Others are better at enterprise-level stability or long-term maintenance. Mixing them up is one of the most common and expensive mistakes companies make.

When you understand your exact goals, timeline, and success criteria, you’ll recognize the right partner faster. They’ll speak the same language, ask the right questions, and shape their process around your priorities.

2. Check Their Process, Not Just Their Portfolio

A good-looking website or impressive case studies can definitely catch your attention. And they are important to have. However, keep in mind that they don’t show how the team really works day to day.

Before signing anything, ask developers about their work process. How do they plan and manage projects? What happens when priorities change? How do they test quality before release? And how will you stay updated on progress?

A reliable partner is open about how things get done. They’ll walk you through their workflow, show you the tools they use, and be clear about who’s responsible for what. That level of transparency tells you a lot more than any list of past clients ever will.

For example, at Empat, we make sure our clients clearly understand the workflow — from the very start of our cooperation and throughout the entire project.

3. Evaluate Communication

Technical skills are very important, but they’re not what make or break a project. According to Statista, problem-solving, effective communication, and relationship-building are the top three soft skills among IT professionals.

In practice, try to notice how the team talks to you from the very first message. Do they reply quickly? Do they explain things in plain language? Do they ask thoughtful questions about your goals instead of jumping straight into tech talk?

These little signs can tell you a lot. A team that listens, challenges your ideas respectfully, and keeps you in the loop is more than just a vendor; they can become your real partner.

Clear, honest communication saves time, prevents mistakes, and keeps everyone focused on the same goal. Without it, even the best code won’t help.

4. Understand Their Tech Choices

Don’t pick a team because they use the latest-sounding framework. It’s better to select them because their choices fit your needs. A good partner will explain the trade-offs and how their stack helps your product, not just name-drop tools.

Ask simple, practical questions:

• Will this be easy to update or extend later?
• Can it handle more users or data without a full rewrite?
• Who owns the code, and how do you hand it over if needed?
• How long will they support the product after launch?
• Are there third-party services that could lock us in or add costs?

The right team talks about long-term maintenance and future features, not only about what they’ll deliver this sprint.

5. Look for partnership, not just service

A good development team doesn’t just do what you ask — they help you make smarter decisions along the way.

You’ll know you’ve found a real partner when:

• They question unclear requirements and suggest better options.
• Someone takes clear responsibility for progress and deadlines.
• They’re open about both results and challenges — and help solve issues, not hide them.
• They focus on how the product performs and supports your goals, not just on closing tasks.

When communication is honest and collaboration feels natural, you’re not just outsourcing work — you’re building together.

6. Red flags to avoid

Small warning signs early usually mean bigger headaches later. Watch for:

• Estimates that feel too good to be true. If the price is extremely low, quality or delivery will likely suffer.
• Vague answers. “We’ll handle it” without details or a plan.
• No single owner. If no one is clearly responsible for the project, tasks slip through cracks.
• Refusal to share references or sample code. Trust is built on proof.
• Evasive on testing or maintenance. If they won’t explain QA or post-launch support, you’ll pay later.
• Constant scope surprises. If requirements keep changing and they blame you, that’s a process problem, not yours.

If something feels off in the first conversations — slow replies, dodgy explanations, or a rush to sign — slow down. Fix it now, or you’ll fix it later at a higher cost.

Conclusion

The right software development partner needs not only to deliver code, but they also have to bring stability, clarity, and long-term impact to your product. At Empat, that’s exactly what we focus on.

• 85% of our developers have strong technical or math backgrounds, which helps us dive deep into complex problems and build truly innovative solutions.
• Nearly 40% of our team has been with us for over two years — proof that we value consistency as much as growth.
• And the most important: our clients are satisfied with our work, which is proven with the 100% positive feedback on Clutch.

So if you’re looking for a team that understands business goals as well as technology, Empat might be the place to start.

At Empat, we work closely with founders building in this new AI-powered reality. What we’re witnessing is more than just a tech shift — it’s a mindset shift. We are entering a new era of launching tech startups, and it’s scarily exciting. It’s Eldorado, and it’s our job to differentiate golden nuggets from shiny wrappers.

AI Tools Are the New Co-Founders

AI tools like Lovable, Claude, Cursor and many others enabled founders to ship their POCs and MVPs with unprecedented speeds while at the same time lowering the bar for technical knowledge required to do so. Operational burden on founders is close to none: you don’t need to spend days/weeks with devs, brainstorming ideas, documenting those, drafting your vision just to realize that it’s not what you meant. Over the weekend, a persistent founder with almost no technical background would be able to build a proof-of-concept (PoC) that 1 year ago would require 2–3 months of work for the small dev team.

The Investment Landscape Is Playing Catch-Up

But where does it all lead us to?

The vast majority of startups depend on capital for their growth, predominantly VCs, but also angels and private equity. That’s a mature industry, with its own processes, tools, methods and selection criteria that’s now being challenged from every corner. Founders drop PoCs on VCs desks that look great, have first users and validated ideas but behind these products there often is zero understanding of underlying risks for future scaling.

Product awareness is close to zero: most founders that rely exclusively on AI for building their product won’t be able to take full ownership of system intelligence, aka they won’t be able to tell you exactly why things work and how they work together. Things just “work”.

VCs, on the other hand, have no technical knowledge or capacity to evaluate these shiny nuggets that look like gold but could just be a wrapper. Before this age of gen-AI on average, over 30% of the seed-round funding went into re-writting the code. Considering an average seed round size of $2m we are talking about $700k to “redo” things. Imagine what will happen now if before we lived in an era where there was at least some intellectual ownership of a product?

And this is where we are entering a real interesting shift in mature economies.

We will definitely see a tectonic shift in how capital is deployed and startups are evaluated but in the meantime, at Empat we developed a package to help VCs quickly evaluate technical readiness of the product before deploying their money into scaling. With fast report turnaround we hope to help both startups requiring additional audit as well as VCs that want to hedge their risks.

We help founders not just move fast, but move smart — building products that are not only impressive at first glance, but deeply valuable over time.

Because in this new gold rush, it’s not just about speed. It’s about knowing where to dig.

Published by Dmytro Naumenko, Head os Sales at Empat

At Empat, we see everything from sharply defined MVPs to beautifully vague requests like “make this feel friendlier, but still serious.” Estimating these can be tricky, but that’s also where the fun begins. Because even if the input is fuzzy, the outcome needs to be clear: how long will it take, and what will we get?

That’s where estimation steps in. Not to predict the future, but to reduce surprises. Done right, a good estimate brings clarity, sets expectations, and gives everyone a fair shot at planning better.

Some tasks feel straightforward:

“Design a landing page.” → We’ve done dozens. Feels like 16–24h.

Others feel like diving into the unknown:

“Redefine the product’s tone across the whole UI.” → Hmm… okay, let’s unpack that.

The trick is not to guess. It’s to structure the guess well enough that it turns into a conversation — and eventually, a plan.

Three ways to size the fog

Over the years, I’ve found three tactics that help bring structure and sanity.

t-shirt sizing (XS–XL)

This one’s great when you’re still in a fuzzy planning stage. You compare the new task to something familiar, then assign a size based on effort, not hours.

It works well when your team shares a mental library of past features. A small marketing banner might be an XS. A moderately complex checkout flow? Maybe a M. A custom analytics dashboard with user roles? Definitely an L or XL.

Behind the scenes, you map sizes to hour bands (e.g., M = 24–40h), so you’re not guessing every time. The key is to revisit and calibrate those ranges regularly.

Optimistic vs. realistic ranges

Once you know 60–70% of the scope, ranges help paint a more honest picture. You give two estimates:

• If all goes smoothly: optimistic
• If there are bumps, feedback, or blockers: realistic

For example, designing five mobile screens might take 16 hours at best, 24 realistically. Communicate the full range, and consider committing closer to the realistic number (with a buffer if needed).

Clients love the lower number, but they respect the thinking behind the higher one.

Buffer time

No matter how smart your guess is, you’ll need margin for the unknown: feedback rounds, handoff hiccups, sick days, someone’s sudden love for neumorphism. Add 15–25% to your estimate. And don’t hide it — make the buffer a visible line item.

Buffer isn’t padding. It’s a safety net for everyone’s sanity.

Combining the three

Here’s a typical path we follow at Empat:

1. Use t-shirt sizes to quickly map early ideas.
2. As scope becomes clearer, break down tasks into ranges.
3. Apply a thoughtful buffer, based on complexity and risk.

You don’t need to pick just one approach. The power comes from knowing when to use each one.

What AI is actually good at (and where you still need a human)

I’ve been using AI as a helpful assistant in our work at Empat long before it became trendy. It’s not just for writing emails — it’s also great for making design estimates more reliable and transparent. Here’s how I personally use it:

• Analyze past work: Based on anonymized trends from past Figma histories or project notes, I use AI to explore average effort per screen type. No sensitive client data is shared — just patterns and context to help shape better estimates.
• Run what-if scenarios: “What if we add another feedback cycle or iteration loop?” LLMs adjust the timeline instantly.
• Catch blind spots: Paste your plan and ask AI to check for forgotten states or flows (empty states, accessibility, localization).

Just remember: AI is like a turbocharged intern. Brilliant at spotting patterns. Terrible at context.

Your free estimation starter pack

Before you panic, Google “UX/UI estimation spreadsheet,” here’s a quick reference table our design team has built from dozens of real projects at Empat. Use it as a starting point — not a rulebook.

Adjust these numbers based on your needs. Add risk indicators. Compare them against your real-world results. Consider this a starting point, not a limitation.

If you want better estimates, build better habits

Getting good at estimation doesn’t come from one great template. It comes from repetition, reflection, and a bit of documentation.

• Track your actuals vs. estimates (yes, even in a spreadsheet).
• Keep your sizing examples up to date.
• Talk about risks early and often.

At Empat, we take estimation seriously — not just because it protects time and budget, but because it helps everyone stay on the same page. We’re lucky to have a sharp New Business team and a super-capable Pre-Sales manager who make our lives a whole lot easier. They break down client needs, ask the right questions early, and keep communication flowing fast and clearly. That kind of support makes it possible for specialists like me to focus on making accurate, thoughtful estimates.

And in the end, clients tell us they feel informed, confident, and listened to. That’s what we’re really aiming for — not just numbers, but trust.

Thanks for reading. If any of this helped you stress less or explain your hours better, mission accomplished.

Published by Andrii Tsabanov, Head of Design at Empat

We are surrounded by AI today. And when I say “today,” I mean May 2025, since in just a couple of months, this information will most likely be outdated. That’s exactly why we decided to test how far AI tools can take you in building actual products — to separate hype from reality. At Empat, we’ve been increasingly encountering cases where clients start building a mobile app using AI tools and then come to us for help to finish it. But that’s a whole other story; let’s take it step by step. Every article tells us about the dawn of software engineers, about how tools like Replit, Vercel, Lovable, Cursor, and others are taking over. But are they really?

Why AI tools don’t magically turn anyone into an app builder

The promise is there; the progress is visible, but we are still waiting to connect the dots and remove the noise. When tractors came to replace horses and bulls in the fields, school teachers did not suddenly become efficient and successful farmers. Those who knew nothing about farming didn’t become farmers overnight. The same way as business founders today are not able to take advantage of these AI tools. It’s one thing to “start the tractor and plow the field”, it’s a totally different thing to yield anything from that field.

Testing AI in the field: two roles, same result

We had a chance to test a number of tools as well as go over the studies and just reflections published by numerous others and here are the largest bottlenecks we see for mass adoption of AI code writing tools as of today. For the sake of clarity of the experiment we used two different approaches: an experienced software engineer using Cursor to build an LMS system and me, an experienced non-technical founder (who also spent over 6 years in business development positions in firms building custom software) using the same application to build a basic mobile app.

The journey was very different, but the results were the same: you cannot rely completely on AI.

AI can get you far, but not far enough if you can’t debug

An experienced engineer was able to achieve an “almost” fully functional web application due to the extensive knowledge of the underlying principles of software development, architecture, and product deployment. An experienced founder, a person who’s driven by “business problems” with basic knowledge of how products are built, was able to build an “almost” fully functional app. The key difference was in the fact that the engineer knew exactly “why” the product didn’t work. A founder just knew it didn’t work, but had no clue why, or where to look for an answer.

To give you a clearer understanding of how the two experiences compare, I’ve put together a simple table that highlights the key differences in how both the engineer and the founder approached building their products using AI. Take a look at the table below for a side-by-side comparison.

The real potential of AI for MVPs

There is no doubt that we will see the time when we can rely on AI more. It will become a major disruptor for building initial PoCs and MVPs to test and validate technical products for small, non-technical teams. But there is a high chance that we will never be able to rely on it completely.

Caution Ahead: Founders Still Need the Fundamentals

Being able to identify the “why” is the major reason why founders should be cautious when using AI to write their code. An experienced farmer knows exactly “why” the yield was lower than expected this year. An amateur just scratches his head and has no idea where to start next year to improve.

So… Should You Build with AI?

In our experience at Empat, we’ve seen how AI tools like Cursor, Lovable, Bolt, and others can help in the early stages of product development, especially if the founder has a basic technical understanding.

Overall, AI can be a powerful tool to accelerate the initial stages, but it’s important to remember that without an understanding of the fundamental principles of development and technical details, creating a fully-fledged product will be challenging.

Published by Dmytro Naumenko, Head os Sales at Empat

AI is everywhere these days. Chances are you’ve already tried ChatGPT at least once, even just out of curiosity. We at Empat started experimenting with AI before it became cool. Naturally, we wanted to go beyond the hype. But we quickly ran into common limitations: models like GPT have knowledge cutoffs and no access to your own data.

Sure, LLMs (Large Language Models) are great for general questions. But in real-world products, AI needs access to your data to be useful — to recommend items, answer questions, assist with support, or analyze internal knowledge. You can technically stuff some of your data into prompts, but that doesn’t scale. In our first prototype — a chatbot that recommends products based on user queries — there was no way we could include tens of thousands of product descriptions in a single prompt.

Back then, we weren’t aware this technique had a name — RAG. Our idea is to use a search to find relevant product descriptions first, then include only those in the prompt in the language model. But a basic keyword search wasn’t enough. Users asked naturally, not with exact keywords.

That’s when we discovered vector search — the ability to search semantically, by meaning, not just by matching words. We used OpenAI’s embeddings + ElasticSearch’s vector capabilities. It was a breakthrough.

Later, we realized this approach had a name: RAG — using search to augment generation.

Beyond Text: What is Multimodal Search?

If embeddings are just vector representations of data, why limit yourself to text? Why not embed images and videos too?

We started looking into models that could generate embeddings for multiple data types and found Google’s Vertex AI multimodal embedding model, which supports text, images, and video. That’s when it clicked: imagine searching your content — documents, screenshots, tutorials — not just by keywords, but by context and meaning. Search your company’s media files like you search Google Photos.

This opens up huge possibilities — and it’s surprisingly easy to build.

Practical Use Cases

You might wonder: where can this actually be used?

Let your imagination run wild:

• Developer Portals & Docs: Search across Swagger files, screenshots, videos, API guides, and diagrams — all in one place.
• Internal Knowledge Tools: Ask questions about onboarding videos, UI workflows, recorded calls, or technical flows.
• Educational Platforms: Ask questions about lectures, slides, and reading material — get answers grounded in mixed media.
• Video Platforms: Power recommendations by matching user questions to relevant video content.
• Support & Help Centers: Users submit a screenshot or describe an issue, and get relevant videos, docs, and error logs.

Architecture Overview

At its core, this project uses a simple and efficient backend stack built with Node.js + Express, chosen to create a minimal and fast microservice for demonstration purposes.

It leverages:

• Google Vertex AI for generating multimodal embeddings (text, image, video)
• Pinecone for storing and querying vector representations

The architecture is intentionally kept simple and easy to extend — and the same approach can be implemented using any backend framework or language you prefer. Whether you’re working with Django, FastAPI, Laravel, or anything else, the principles behind RAG and multimodal search remain the same.

So, pick the tools you like best — and build it your way.

Implementation Steps

The full implementation of this backend is already available in the public repository: https://github.com/ym-empat/multimodal-rag-nodejs

Below are explanations for each of the main files in the repository. The code shown in the article is taken directly from this repo. Feel free to use, adapt, and build on top of it — it’s open and ready for experimentation.

1. .env - Environment Configuration

PORT=3000

GCP_LOCATION=us-central1
GOOGLE_APPLICATION_CREDENTIALS=./service-account.json

PINECONE_API_KEY=example_api_key
PINECONE_INDEX_NAME=example_index

This file contains all necessary configuration values. It defines the server port, GCP project location, path to your service account credentials, and Pinecone API/index configuration. You must:

• Create a service account in Google Cloud with access to Vertex AI and download the key as service-account.json.
• Create a Pinecone index and copy its name and API key.
• Use a region (GCP_LOCATION) where Vertex AI multimodal embedding is available, like us-central1.

2. app.js - API Server (Express)

This is the main entry point of the application. It sets up the Express server, configures file uploads via multer, and defines two routes: /upload and /search/text. The /upload endpoint handles both text and file inputs (images or videos), determines the content type, and sends it for embedding and storage. The /search/text endpoint receives a text query, vectorizes it, searches for matches in Pinecone, and returns metadata about the most relevant results.

const express = require('express');
const dotenv = require('dotenv');
const multer = require('multer');

const { embedText, embedImage, embedVideo } = require('./vertex');
const { upsertToIndex, search } = require('./pinecone');

dotenv.config();

const app = express();
const port = process.env.PORT || 3000;

const upload = multer({ storage: multer.memoryStorage() });

app.use(express.json());

app.get('/', (req, res) => {
    res.status(200).json({ message: 'OK' });
});

app.post('/upload', upload.single('content'), async (req, res) => {
    const file = req.file;
    const text = req.body.content;
    const filename = file?.originalname || 'text_input';

try {
        if(file) {
            const mime = file.mimetype;

if (mime.startsWith('image/')) {
                
                console.log('embedding image');
                const vector = await embedImage(file);
                await upsertToIndex({ vectors: [vector], type: 'image', filename });
            
            } else if (mime.startsWith('video/')) {
            
                console.log('embedding video');
                const vectors = await embedVideo(file);
                await upsertToIndex({ vectors, type: 'video', filename });
        
            } else {
                return res.status(400).json({ error: 'Unsupported file type' });
            }
        } else if (text) {
            
            console.log('text');
            const vector = await embedText(text);
            await upsertToIndex({ vectors: [vector], type: 'text', filename: 'text_input' });
       
        }

res.status(200).json({ message: 'OK' });
    } catch (err) {
        console.error(err);

res.status(500).json({ message: 'Internal Server Error' });
    }
});

app.post('/search/text', async (req, res) => {
    const { query } = req.body;

if (!query || typeof query !== 'string') {
        return res.status(400).json({ error: 'Invalid or missing "query" field in JSON body' });
    }

try {
        
        const vector = await embedText(query);
        const results = await search(vector, 3);
        res.status(200).json({ results });
        
    } catch (err) {
        console.error(err);
        res.status(500).json({ error: 'Search failed' });
    }
});

app.listen(port, () => {
    console.log(`Server is running on <http://localhost>:${port}`);
});

3. vertex.js - Vertex AI Integration

This module connects to Google’s Vertex AI multimodal embedding model using the official REST API. It defines three functions: embedText, embedImage, and embedVideo. Each function sends the appropriate type of input to the model and returns the embedding(s). For videos, the full file is sent with a configuration that tells the model to return multiple embeddings - one per 15-second segment - each enriched with timing metadata.

const { GoogleAuth } = require('google-auth-library');

const location = process.env.GCP_LOCATION || 'us-central1';
const dimension = 1408;

const auth = new GoogleAuth({
    scopes: '<https://www.googleapis.com/auth/cloud-platform>',
});

async function getClient() {
    const client = await auth.getClient();
    const projectId = await auth.getProjectId();
    const url = `https://${location}-aiplatform.googleapis.com/v1/projects/${projectId}/locations/${location}/publishers/google/models/multimodalembedding@001:predict`;

return [client, url];
}

async function embedText(text) {
    [client, url] = await getClient();

const res = await client.request({
        method: 'POST',
        url,
        body: JSON.stringify({
            instances: [
                {
                    text
                }
            ],
            parameters: {
                dimension
            }
        })
    });

return res.data.predictions[0].textEmbedding;
}

async function embedImage(image) {
    [client, url] = await getClient();

const res = await client.request({
        method: 'POST',
        url,
        body: JSON.stringify({
            instances: [
                {
                    image: {
                        bytesBase64Encoded: image.buffer.toString('base64')
                    }
                }
            ],
            parameters: {
                dimension
            }
        })
    });

return res.data.predictions[0].imageEmbedding;
}

async function embedVideo(video) {
    [client, url] = await getClient();

const res = await client.request({
        method: 'POST',
        url,
        body: JSON.stringify({
            instances: [
                {
                    video: {
                        bytesBase64Encoded: video.buffer.toString('base64'),
                        videoSegmentConfig: {
                            intervalSec: 15
                        }
                    }
                }
            ],
            parameters: {
                dimension
            }
        })
    });

return res.data.predictions[0].videoEmbeddings;
}

module.exports = {
    embedText,
    embedImage,
    embedVideo
};

4. pinecone.js - Vector Storage and Search

This module manages interaction with the Pinecone vector database. It provides functionality to upsert vectors with metadata (upsertToIndex) and to query for nearest matches (search). All vectors are stored in a namespace, and each includes metadata such as filename, type, and**,** optionally**,** segment time (for videos). The search function performs similarity matching and returns only the metadata of the top results.

const { Pinecone } = require('@pinecone-database/pinecone');
const dotenv = require('dotenv');

dotenv.config();

const pinecone = new Pinecone({
    apiKey: process.env.PINECONE_API_KEY
});

const indexName = process.env.PINECONE_INDEX_NAME;

const index = pinecone.index(indexName);

async function upsertToIndex({ vectors, type, filename }) {
    const pineconeVectors = vectors.map((v, i) => {
        const id = `${filename.replace(/\\W/g, '_')}_${Date.now()}_${i}`;
        const metadata = {
            type,
            filename,
        };
    
        if (v.startOffsetSec !== undefined) metadata.startOffsetSec = v.startOffsetSec;
        if (v.endOffsetSec !== undefined) metadata.endOffsetSec = v.endOffsetSec;
    
        return {
            id,
            values: v.embedding || v,
            metadata,
        };
    });

console.log(pineconeVectors);

await index.namespace('ns1').upsert(pineconeVectors);
}

async function search(vector, topK) {
    const response = await index.namespace('ns1').query({
        topK,
        vector,
        includeMetadata: true,
    });

return response.matches.map(match => match.metadata);
}

module.exports = {
    upsertToIndex,
    search
};

Output & Limitations

This backend is intentionally minimal and API-only. Its main purpose is to demonstrate how to build a working multimodal RAG system using modern tools like Vertex AI and Pinecone. When uploading content, the API returns a simple confirmation message indicating success. When performing a search, the API responds with metadata describing the top matching results — such as the filename, content type, and video segment timestamps (if applicable). No embeddings or file contents are returned, and no front-end interface is provided.

The current implementation lacks authentication, deduplication logic, and advanced filtering or ranking strategies. Each upload is stored as a new item, and the system does not track ownership or user sessions. The semantic search results rely entirely on embedding similarity and may require tuning (e.g., adjusting topK or score thresholds) in production use cases.

This minimal setup is ideal for experimentation, rapid prototyping, or as a foundation for more advanced systems that build upon it.

What’s Coming Next

In Part 2, we’ll build on top of this RAG backend and add:

• A chatbot interface using Gemini
• Session memory: so the assistant can “remember” previous questions
• Full conversation support over your multimodal data
• Image / Video input to chat

Stay tuned — and if you’re a dev, feel free to fork the repo and try it out.

At Empat, we’ve already built multiple real-world projects using RAG-based architectures — including document processing systems for the construction industry, post-mortem analysis tools for completed projects, and LLM-powered bots that assist teams in making sense of large internal knowledge bases. We’ve tested these patterns across domains, and know how to make them work in practice.

If you’re exploring how to apply RAG in your own product or workflow — feel free to reach out.

Published by Yaroslav Melnychenko, Backend Lead at Empat