Why a software company runs Moldova’s biggest developer conference

FusionWorks has organized Moldova DevCon since 2011. On November 6–7, 2026, the 18th edition brings more than 1,000 developers to Chișinău Arena. Here is why a software company does this, and what you get if you come.

Why we run it

We are an engineering company. Everything we ship depends on the people around us: the engineers we hire, the companies we partner with, the students who become our colleagues. That community doesn’t build itself. Moldova DevCon is how we build it, and our stubborn promise that Moldova can have its own big tech event.

Why it matters more now

Many developers wonder whether their profession has a future. The market has shrunk, and AI is changing how code gets written.

“Waiting it out is not a strategy. The people who stay in demand learn to work with AI, not against it, and understand what problem their code solves,” says Anton Perkin, CEO of FusionWorks and organizer of MDC. “At MDC, specialists from Google, AWS and Perplexity AI will tell you specifically what has changed in their work and which skills matter now.”

AI made knowledge cheap. Experience is still scarce, and you get it from people who have already done the thing: on stage, at the coffee break, at the expo.

Expo zone at Moldova DevCon

What you get in two days

  • Talks you can use: agentic SaaS with A2UI and microfrontends (AWS), delegating work to agents (Perplexity AI), AI in highly regulated environments (Trade Republic), securing the software supply chain (Wise), what is eating your LLM tokens (EIS Group).
  • Workshops: building AI agents with ADK and MongoDB Vector Search; experimenting without breaking production (Orange Systems).
  • People: speakers from eight countries, hiring companies at their stands, and the community you will keep working with after November.
  • Three evenings: the pre-party on Thursday, the Wine & Tech dinner with speakers on Friday (Geek tickets), the afterparty on Saturday.
Attendees at Moldova DevCon, organized by FusionWorks

Who we build it with

FusionWorks organizes the event; Orange Systems is the general partner. The Ministry of Economic Development and Digitalization, MITP, Innovate Moldova, Moldindconbank and companies from Moldova’s IT sector support it, together with universities, student NGOs, tech communities and media partners.

Join us

Tickets: mdc.md/tickets. Group offers and partnerships: mdc@fusionworks.md.

We replaced Odoo with an ERP we built in a week

This summer we stopped paying for Odoo. Since September, dozens of people at FusionWorks log thousands of hours a month, run the CRM, plan resources and manage contracts in Ops — our own ERP, built by our automated development pipeline in one week in August and tested by the team for two.

We replaced Odoo with our own system. Every company will. Generic software you rent is being replaced by software built for you, and we happened to go first. Here is how it went, and how to do it yourself.

Sales pipeline in Ops: deals by stage on the CRM board
Ops today — the sales pipeline that used to live in Odoo. Names and clients are anonymised in all screenshots.

What Odoo did for us, and what it didn’t

Odoo was our ERP for years: timesheets, CRM, planning, contracts, projects. A decent product. The problem is not Odoo. The problem is generic software.

Every SaaS has two feature lists. The first is what you pay for and never open. The second is what you need and cannot get. The second list is the expensive one.

For us the second list looked like this:

  • validation of hours against each person’s real capacity, not a hard-coded 8-hour day
  • a project margin that connects rates, cost and logged time in one place
  • a way for our AI assistants to work with the CRM and planning directly, without an integrator in between

Adding any of these to Odoo meant an integrator, a quote and a month. We asked twice. Then we stopped asking.

Resource planning in Ops: people, projects and load per week
Resource planning in Ops — the module we could never bend to our process in a generic ERP.

Why this was irrational three years ago

Building your own ERP was a corporate luxury. It meant six months, three engineers and a system nobody wanted to maintain afterwards. Buying was the only rational choice, and we made it — like everyone else.

With AI-native development the math flipped. What made the week possible is the way we build everything now — our 24*7 development framework: an automated pipeline where agents write code through the night and engineers direct, review and take responsibility in the morning. 168 hours a week, not a month. We described the modules on a Monday. One week later Ops was running with real data. Two weeks later the whole team had tested and polished it. In September we switched.

The cost of building dropped by an order of magnitude. But the bigger change is the cost of changing. A new field, a new report, a new rule used to be a project. Now it is a conversation before lunch.

None of this is specific to a software company. A logistics firm, a clinic, a law office, a manufacturer — each runs on three or four generic systems it tolerates. Each can now have its own.

A month of logged hours by project in Ops
A month of logged hours by project in Ops.

What we actually got

  • Only the features we use. CRM, timesheets, resource planning, contracts, directory. Nothing else on the screen.
  • Changes in hours. Our fixes ship the same day. A vendor’s roadmap no longer decides what our Tuesday looks like.
  • Our data in our database. Every report, every export, every integration is ours.
  • A system built for AI too. Ops has an MCP endpoint. “Who is free next week?” is a question Claude answers from Planning, not from a guess — and it can log the answer back.
Agent activity log in Ops: calls by person, by connection and by day
Every agent call against Ops is recorded: who asked, through which connection, and what was refused.

What broke

Honesty is part of the story. On day one most of the team had no login — we had forgotten an invite flow. A validation error wiped a whole form. Typing 0 in a timesheet cell did nothing.

All of it was fixed within days, because the fix was ours to make. One week to build. A month to make it boring.

And it didn’t stop at Odoo. In October our HR tool — vacations, sick leaves, remote days — moves into Ops as well. Two subscriptions, one system built for us.

Now we do this for other companies

Every company has its Odoo: the HR tool nobody likes, the CRM with forty unused fields, the spreadsheet with macros that one person understands. You tolerate it because building your own was irrational. It isn’t anymore.

Here is what we offer.

A system built for you, quickly. We build with your stakeholders in the room, on the same 24*7 pipeline that built Ops: agents through the night, engineers in the morning. Week one — build. Weeks two and three — your team tests, we fix daily. Week four — run in parallel with the old system, then cancel the renewal.

Inexpensive. One senior engineer directing the pipeline, not a team on a six-month contract. You pay for the system, not for the features you will never open.

Self-supporting. The system updates itself and suggests new features based on how your team uses it. Your own people can add features — a description is enough; the system does the rest.

A guide, not a lock-in. After delivery we hand over a guide on how your team keeps improving the system on its own. And if you would rather not — we support it.

We did it for ourselves first. Ops is the proof: dozens of people, hundreds of projects, thousands of hours a month, and zero integrators.

The full offer — scope, timeline, what you own at the end — is on our Custom ERP page.

Tell us which system is your Odoo

How we partner with product teams: the Allasso story

Most traders make decisions somewhere between using a spreadsheet and their gut feeling. One is too slow to keep up with the market, the other is too expensive to be wrong about. When Allasso came to FusionWorks, they wanted to give financial professionals a third option: a workspace where a trade could be tested, stress-checked, and understood before any real money moved.

What you are about to read is less a portfolio piece and more a description of how we work. Allasso is the example, but the pattern is the point. We treat companies that hire us as long-term product partners, and the work below is what that looks like when it plays out over a couple of years.

Starting small, on purpose

The first version of the product did exactly one thing: the trader picked a single instrument, for example,  gold or the S&P 500, and ran “what if” scenarios against it. They could change the price, the volatility (the number traders watch to guess how wild the market is about to get), and the inputs that drive the market underneath, then watch the consequences update in seconds.

The work that used to live in a spreadsheet, calculated by hand and prone to small errors with large costs, now happened inside a tool built for the job. Assumptions could be tested instead of being guessed.

We could have proposed a much bigger first build but we didn’t. Because a smaller first version meant Allasso’s users could touch the product sooner and tell us what was actually missing. That early feedback is what shaped every decision after it.

Letting the product grow from real usage

As traders spent time inside the tool, they started asking for more context around each decision, so we built outward in layers rather than starting over. Historical charts came in to ground the scenarios in what the market had done. Risk analysis arrived next, then calculated outputs, followed by new ways to look at the same trade from different angles. Each addition wrapped around the existing workflow instead of replacing it, which meant nobody had to relearn a tool they already trusted.

This is the part of the partnership we care most about. It is easy to build the thing on the brief. It is harder, and more useful, to keep building in a direction that respects what users have already learned.

Knowing when to throw something away

The first version of the charts was built with a tool called Plotly. It got us moving fast, which was the right call at the time. But as traders pushed the product harder, they needed charts that behaved in very specific ways.

So we moved to D3, which gave us full control over how every chart looked and how every interaction behaved. That switch unlocked the visualizations we couldn’t have built before, and it set up everything that came after. Part of being a real partner is telling a client when it is time to replace something we built ourselves, and then doing the replacing without friction for the users.

Growing past the original scope

Over the last year, the product has grown well beyond the single-screen tool we started with. Together, we built two new modules that opened up entirely new ways of working.

The first, Quotes, lets traders work with several instruments at once. They could compare positions side by side, edit quote structures, and recalculate multiple positions inside a single workflow instead of jumping between tabs. The second, Volatility, gave traders direct, visual control over volatility surfaces and smiles (the maps traders use to price options across different scenarios). They could adjust values by hand, publish the structures they built, and reuse those calculations elsewhere in the platform.

Around this point, something quietly important happened. The separate pieces of the product started talking to each other, and the workspace stopped feeling like a collection of features. It started feeling like one connected environment, which is exactly what a trading tool needs to be.

Meeting traders in their own language

Once the platform was mature, we kept noticing the same small friction – when a trader has an idea, they describe it in shorthand: the thing they want to trade, the period, a few numbers, whether they are betting on the price going up or down. Then they sit down at the screen and translate that shorthand, click by click, into a structure the system understands. The idea is fast. The data entry is slow.

So we built an AI-powered structure recognition directly into the application. A trader can type their idea the way they would say it out loud, naming the underlying (the asset the trade is based on, like gold or an index), the contract period, the strike prices (the price levels where the trade pays off), the quantities, the call and put legs (the individual up-bets and down-bets that make up the position), and the target price. The system reads that shorthand and turns it into a fully formed structure inside the app, ready to test.

The result is a workspace where structure creation is faster, manual input drops, and the tool finally meets traders where they already are, instead of asking them to translate themselves into it. This is the philosophy the whole partnership has run on: watch how the work happens, then shape the product around it.

What we are building next

Today, charts, quotes, volatility analysis, shared structures, exports, and trading calculations all live inside one connected ecosystem. FusionWorks is still building with Allasso, and the next phase is taking some of the individual chart and analytics components out into standalone libraries so they can run anywhere: JavaScript apps, Python notebooks, future trading products that have not been designed yet.

The product started as one instrument on one screen. It became a set of tools shaped around the way traders work – 100 features built across 700 tasks, because the team behind it kept pushing the boundaries and we kept showing up with the right solutions. That, more than any single feature, is what we mean when we say partnership.

How we build software at FusionWorks

FusionWorks is an AI-native software delivery company. Not AI-assisted. Not AI-curious. AI-native – meaning the entire delivery model is built around it.

This is a deliberate bet. While most companies bolt AI tools onto existing processes, we redesigned the process itself. Every workflow, every team structure, every quality gate is engineered for a world where AI writes a significant part of the code and humans provide the judgment, architecture, and standards that make it production-ready.

What AI-Native means in practice

Strong engineers, not cheap labour. When AI handles routine implementation, the value of an engineer shifts. We hire people who think well – who understand real customer problems, make architectural decisions, and iterate fast. Curiosity, judgment, and speed of learning matter more than typing speed.

Systems and workflows, not chaos. AI amplifies whatever you feed it. Feed it chaos, and you get faster chaos. Feed it a structured, factory-like process – with clear quality gates, defined architecture, and repeatable standards – and you get consistent, reliable output at speed. We chose the second option.

Smaller teams, faster cycles. The old agency model scaled by hiring. More people, more revenue, more coordination overhead. Our model scales differently: strong engineers + strong process + strong AI automation. Smaller teams move faster, deliver more, and maintain higher quality.

Architecture and judgment, not endless manual implementation. Human experts design the workflows, quality gates, architecture, and decisions. AI helps us deliver faster, with more consistency and less waste. This isn’t about replacing engineers — it’s about removing the parts of the job that didn’t require engineering in the first place.

Production-ready standards, not demo-level hype. Anyone can build something that looks real using AI. Then reality hits: authentication, payments, data migrations, CI/CD, security, performance. We bridge the gap between prototype and production — with the speed and cost-efficiency that AI-native delivery enables.

Why this matters for our clients

If you’re a founder who built an MVP in Lovable or Figma and needs it live in production – we take it there. If you’re an established company that needs a reliable engineering partner – we deliver with predictability, not just promises.

Our delivery runs on a clear structure: AI embedded in the actual workflow (not in a slide deck), clear scope per sprint, weekly demos, and production-ready standards from day one. Less dependency on random talent. More reliability with real engineers and a strong system.

The shift we’re making

Traditional outsourcing was never a great scalability story. Revenue grew with headcount. Margins stayed thin. Everything was people-dependent.

We’re building something different – a tech company with its own way to develop software. A factory-like process, engineered by humans, automated by AI. We own the process, the expertise, and the technology behind delivery. That’s how an outsourcing company becomes a real tech partner.

Better systems, not bigger teams. The future of software development is not bigger teams. It’s efficiency built with systems.

And we’re already there.

Are you joining? Email us at team@fusionworks.md

From Lovable to Production: How to Build a Real Production Environment Without Leaving Lovable Behind

You built something real. You took an idea, opened Lovable, and turned it into a working product: a frontend, backend logic, a database, auth. It works and users are signing up. But now you’re starting to feel the friction.

Maybe Lovable went down and your app went with it. Maybe someone on your team pushed a change that broke something in production and there was no review process to catch it. Maybe you just want to know that your production environment is yours: stable, predictable, and under your control.

The good news: you don’t have to abandon Lovable to get there. You can keep building in Lovable while running a proper production environment alongside it. That’s exactly what we help founders do at FusionWorks, and this article walks you through how we approach it.

The Core Idea: Lovable for Development, Production on Your Terms

The migration most people imagine is an all-or-nothing move: rip everything out of Lovable, rewrite what you need, and never look back. That’s expensive, risky, and usually unnecessary, especially at the stage where you’re still iterating fast.

What we propose instead is a dual-environment setup:

  • Lovable stays your rapid prototyping and development tool. Founders and non-technical team members can keep making changes there.
  • A separate production environment runs on infrastructure you control – Cloudflare Pages for the frontend, Supabase’s own cloud for the backend and database.
  • GitHub sits in the middle, syncing changes from Lovable to production through pull requests and a proper review process.

This means you get the speed of Lovable and the stability of a controlled production deployment. Changes flow from Lovable through GitHub, get reviewed (by your team or ours), and only then reach your users.

What Lovable Is Actually Made Of

Before you can migrate anything, you need to understand what Lovable assembled for you under the hood.

Lovable uses Supabase as its backend layer. Your database, your Edge Functions, your authentication, it all lives in a Supabase project that Lovable manages on your behalf. The frontend is a standard SPA (Single Page Application) built with Vite and React, and Lovable handles the build and deployment for you.

When you connect Lovable to GitHub (which you should do immediately if you haven’t), you get a repository with two main areas: a src folder containing your frontend code and a supabase directory containing your Edge Functions code and database migrations.

That repository is your escape hatch. Everything you need to run independently is in there, with a few catches we’ll get to shortly.

The Migration Path: Step by Step

1. Audit Your Repository

Start by pulling down your Lovable-connected GitHub repo and actually reading through it. Pay special attention to two things:

Database migrations. Lovable generates these as you build, but the ordering isn’t always clean. We’ve encountered cases where a security policy for a table was created in a migration that ran before the migration that created the table itself. Go through the migration files in order and make sure each one only references objects that already exist at that point in the sequence. You may need to reorder or merge a couple of files.

The config.toml file in the supabase directory. This contains your Supabase project configuration: the project ID it’s linked to, which features are enabled, and importantly, the JWT verification settings for your Edge Functions. We’ll come back to this.

2. Set Up Your Production Infrastructure

We recommend the following stack for most Lovable migrations – it’s cost-effective, gives you full control, and each piece can be swapped independently later:

Supabase Cloud for your database, Edge Functions, and authentication. You’ll create a new Supabase project directly on supabase.com. This gives you access to features and configuration options that Lovable’s managed Supabase instance doesn’t expose.

Cloudflare Pages for your frontend. The free tier is generous and more than sufficient for most early-stage products. It gives you global CDN, automatic builds from GitHub, and preview deployments for every branch.

The key benefit of this split: each piece runs on infrastructure optimized for its purpose, and you’re not locked into any single vendor.

3. Navigate the Supabase Gotchas

This is where real-world experience saves you hours of debugging. Here are the issues we’ve hit and solved:

API key types. Supabase has different types of API keys, and Lovable may have been using legacy keys. Before you update your codebase to use the new project’s keys, check which type Lovable was using and make sure you match it or deliberately migrate to the newer format.

JWT verification on Edge Functions. By default, Supabase Cloud enables JWT verification on all Edge Functions. Lovable typically disables it. If you deploy your functions and immediately start getting 401 Unauthorized errors even though your keys are correct, this is almost certainly the cause. Check that your config.toml has verify_jwt = false under each function definition or better yet, take this opportunity to properly implement JWT verification.

Data API settings. The inverse problem: Lovable enables the Data API by default, but a fresh Supabase project has it disabled. If your Edge Functions are calling Supabase’s REST API internally, you’ll need to flip this on.

4. Deploy Your Frontend to Cloudflare Pages

Connect your GitHub repository to Cloudflare Pages and set up a build. A few things to watch for:

The lockfile problem. Cloudflare’s default build tool is Bun, and if there’s a bun.lock or bun.lockb file in your repo (Lovable may have created one), Cloudflare will use Bun regardless of what you want. If your project was built with npm, delete the Bun lockfile from your repo. This avoids subtle dependency resolution differences that can cause build failures.

SPA routing. This one bites everyone. Lovable handles SPA routing internally and doesn’t export any routing configuration to your repo. When you deploy to Cloudflare Pages, navigating directly to any route other than / will give you a 404. You need to configure Cloudflare to serve your index.html for all routes. The simplest approach: add a _redirects file to your public folder with /* /index.html 200.

Branch configuration. Since we’re maintaining backward compatibility with Lovable, we recommend creating a dedicated branch for your production deployment (e.g., production). Configure Cloudflare Pages to build from this branch. Changes from Lovable flow into main, get reviewed, and are merged to production when ready.

Domain and auth settings. Once your Cloudflare deployment is live (either on a custom domain or the preview URL), go back to your Supabase project and update the URL Configuration in Authentication settings. Without this, OAuth flows and email links will point to the wrong place.

5. Handle the Lovable AI Dependency

This one catches people off guard. If your app uses any AI features – chatbots, summaries, document Q&A, sentiment analysis, image understanding – Lovable provides those through its own AI proxy called Lovable AI. It gives your app access to models like Gemini, GPT-5, and others without requiring you to set up API keys or billing with providers directly. It just works inside Lovable.

The problem is that Lovable doesn’t expose this API for use outside their platform. Once your app is running on your own infrastructure, any feature that calls Lovable AI will simply stop working.

You have a few options here, and which one you pick depends on how you want to manage the transition:

Option A: Replace with OpenRouter. This is our recommended approach for most cases. OpenRouter gives you a single API that routes to dozens of LLM providers: Anthropic, Google, OpenAI, and more. You swap out the Lovable AI calls for OpenRouter calls, keep one API key, one billing account, and you can switch between models without changing your code. It’s the closest equivalent to what Lovable AI was doing for you.

Option B: Go direct to providers. If you know exactly which model you need (say, Claude for your chatbot, Gemini for image analysis), you can integrate with each provider’s API directly. More control, but more API keys and billing relationships to manage.

Option C: Make it configurable. This is the approach we often take when founders want to keep building in Lovable while running production separately. You abstract the AI call behind a configuration flag – in the Lovable development environment, it uses Lovable AI; in production, it routes through OpenRouter or a direct provider API. Same codebase, different backends depending on where it’s running. This preserves full backward compatibility with Lovable while giving production its own reliable AI layer.

Whichever route you choose, the code changes are usually straightforward, Lovable AI calls follow a standard pattern, and replacing them with an OpenRouter or direct API call is mostly a matter of swapping the endpoint and adding an API key from environment variables.

6. Establish the Sync Workflow

This is where the real value of our approach becomes clear. Here’s how the day-to-day workflow looks:

  1. Founders and team members build in Lovable as they always have. Lovable pushes changes to the main branch on GitHub.
  2. A pull request is created from main to production (this can be automated).
  3. The PR gets reviewed, either by your team or by FusionWorks engineers. This is the quality gate. We check for breaking changes, security issues, and anything that shouldn’t go to production without testing.
  4. Once approved, changes merge to production and Cloudflare automatically builds and deploys.
  5. Professional development work (bug fixes, performance improvements, features that need proper engineering) happens on feature branches, goes through its own PR process, and merges to production independently.

This gives you the best of both worlds: Lovable’s speed for rapid iteration and a professional engineering workflow for production stability.

Why This Matters

We’ve seen it too many times: a founder builds something great in Lovable, gets real users, and then hits a wall. Lovable has an outage and their product goes down. An accidental change breaks something critical. There’s no staging environment, no review process, no way to roll back.

Going from a working prototype to a production-grade setup doesn’t have to mean a complete rewrite. It means putting the right infrastructure and processes around what you’ve already built.

At FusionWorks, we’ve been building production software for over a decade. We know how to take what you’ve created in Lovable, which is real, working code, and give it the production foundation it deserves. And we do it in a way that lets you keep moving fast in Lovable while your production environment stays rock solid.


FusionWorks helps founders migrate from AI-powered platforms to production-grade environments. If you’ve built something in Lovable and you’re ready for production stability without slowing down, get in touch.

ISO certifications aren’t a trophy. They’re a promise you can verify

Software projects often fail in boring ways, because of unclear process, inconsistent quality, or weak data handling. That’s exactly what ISO standards are designed to prevent, especially in the AI era.

We are certified for the latest versions of:

  • ISO/IEC 27001 — information security management
  • ISO 9001 — quality management

These certifications were issued after an independent audit by TÜV AUSTRIA. So this isn’t “trust us” marketing. It’s an externally checked system that we run every day.

So why should you care about this?


What you get as a client (from lower risk to easier compliance)

First of all, lower risk for your data and your business

If your product handles customer data, payments, internal business logic, or anything sensitive, you don’t want improvisation. We assess risks, protect assets, and use clear rules for handling sensitive and personal data. Security covers also delivery, IT operations, and the people/process side too. Even the physical side matters: access control, networks, and basic office security are part of the system.

More predictable delivery (less hero work)

Many teams can build features, but fewer can deliver consistently when things get messy, like scope changes, urgent fixes, new people joining, shifting priorities and so on.

ISO 9001 pushes discipline into the boring parts that decide outcomes:

  • Clear, repeatable delivery process
  • Quality checks built into the workflow (not “we’ll test later”)
  • Continuous improvement instead of repeating the same mistakes
Faster vendor approval and easier compliance

If you’re in a company that takes security seriously (or must — finance, healthcare, SaaS with enterprise clients), you know the pain: questionnaires, audits, procurement checks.

ISO certification makes the conversation easier because we already have the system and evidence in place. You spend less time “evaluating the vendor” and more time shipping the product.


Why this matters when choosing a development partner

Most competitors will say: “We care about quality” and “We take security seriously.”

ISO is the difference between a claim and a mechanism.

It means we don’t rely on luck, individual habits, or a single “strong PM” to keep things under control. The company is built to deliver reliably — even as the team scales, people rotate, and the product evolves.


As a result, your data is handled with a real security system, your delivery becomes more predictable and your vendor risk goes down — which matters a lot when stakes go up.

If you want a team that ships fast and operates like a long-term partner — let’s talk.

Book a call  or  Get a quote

Why FusionWorks Became More Open to Fixed-Price Projects

For more than a decade, FusionWorks has mostly preferred time-and-materials projects. Not because we didn’t like fixed prices, but because they rarely worked in the real world of modern software development.

Why FusionWorks Became More Open to Fixed-Price Projects

In Agile, nobody writes 200-page “waterfall” specifications anymore. Requirements evolve. Users learn what they actually need only when they finally see the first version. And every small change, even a reasonable one, requires human time. But human time is slow and expensive.

So, historically, fixed-price meant one of two things:

  • You load the project with a massive risk buffer, which nobody likes.
  • You accept the risk and pray that the requirements won’t shift too much, which they always do.

And that’s why, even when clients pushed for fixed prices, we were careful, conservative, and preferred T&M. We wanted to always deliver what the client really needed, not just what’s written in the document.

Then something fundamentally changed.

AI Changed the Equation

With angen.ai and our internal “AI-at-every-stage” development pipeline, the nature of change transformed itself.

The real cost of change has never been the conversation. It’s not about writing a sentence like “add a filter here” or “extend this workflow.” The real cost was always in the coding.

Developers needed a day or two (sometimes a week) to rewrite pieces of the system. And multiplied by any European rate, this becomes real money, which is exactly why fixed-price budgets used to be so fragile.

AI broke that bottleneck. Today, our teams can:

  • regenerate modules in hours, not days
  • rewrite architecture-consistent code in bulk
  • apply change requests extremely fast
  • keep code quality, patterns, and standards intact
  • maintain predictable velocity because AI removes human bottlenecks. 

We suddenly have more “budget room” inside the same fixed price.

If earlier 80–90% of the budget was spent on pure coding effort, now AI reduces that dramatically. That free space can absorb many of the natural requirement shifts that happen during a real project without blowing up the budget, team morale, or delivery timeline.

Fixed Price Becomes Fair Again

This new reality allows us to offer fixed-price projects in a way that feels healthy for both sides. 

For clients

  • predictable budget
  • less fear of the classic “change request” stress
  • faster delivery
  • more flexibility during development
  • same quality, but multiplied by AI speed.

For us

  • less risk
  • more consistency
  • less time wasted on manual coding
  • more space to handle changes within the planned scope
  • a clear, reliable delivery pipeline powered by angen.ai.

We are no longer afraid that a small product correction will cost two weeks of human time. Now it’s usually a couple of hours of AI-assisted regeneration plus human supervision.

A New Era for Our Delivery Model

So yes, for the first time in many years, we at FusionWorks become genuinely open to fixed-price projects again. Because our capabilities changed.

AI makes software development faster, more predictable, and more resilient to changes. And when the coding bottleneck shrinks, the whole fixed-price model becomes much more practical and much more fair.

In the end, fusion of human engineering + AI automation is exactly what makes this possible.

And that’s what angen.ai was built for.

Moldova DevCon: why it’s for you?

Moldova DevCon is the largest and most prestigious event for developers in Moldova. Bringing together top engineers, tech leaders, and industry giants from across the globe, #MDC offers 2 days of engaging presentations, hands-on workshops, and networking opportunities at the stunning Arena Chisinau, the biggest venue in the country!

We’ve prepared for you something huge this year — a new venue, format, and scale. But why you should be there? Let’s see.

#1 Learn from companies and engineers from all over the world

IBM, Amazon, Electrolux, ASML, Pirate, Germany, Netherlands, South Africa, Sweden, Finland, Croatia, Serbia, North Macedonia, Romania and Moldova — this is the new scale of Moldova DevCon 2024. And you’ll be a part of it.

At #MDC you can expect sessions on cloud computing from Amazon’s engineers, who will dive into cloud infrastructure optimization and serverless architecture. AI and machine learning enthusiasts will have a chance to learn from IBM professionals about integrating AI solutions into scalable systems. Experts from Electrolux will share their insights into IoT (Internet of Things) and how it’s revolutionizing industries globally.

Mobile development is also a hot topic at MDC 2024. We’ll look into Kotlin Multiplatform, showcasing how Android and iOS developers can work more efficiently with shared codebases. There will also be deep dives into Android development and cross-platform solutions.

You’ll also hear from cybersecurity experts discussing the latest in application security and data privacy, particularly in the context of European regulations. DevOps professionals will share best practices for automating infrastructure and improving continuous integration pipelines.

With the technical depth and variety, we’ll ensure that there’s something valuable for every developer, whether you’re looking to specialize or broaden your tech horizons.

#2 Get a job you want

We invited industry leaders to join us as partners and they said YES. Here is the list of companies that will have their booths at the event. Traditionally they are here to offer you something awesome, including job opportunities. You’ll have enough time to go through all of them and explore the opportunities. Don’t miss a great chance to boost your career and build new relations!

Ready to join us? Don’t miss your chance to experience #MDC in full. Use promo code ‘igotomdc’ and grab your ticket now for an exclusive discount. Register here and secure your spot!

#3 Enjoy the time with other tech people

The communication is key. That’s why we hate online formats and focus on events where you can meet and talk with people who think alike.

We’ve carefully curated networking breaks, coffee sessions, and after-event activities to ensure you can meet and exchange ideas with tech professionals, potential employers, and industry leaders. Whether you want to collaborate on projects, discuss the latest innovations, or simply connect with like-minded individuals, MDC provides the perfect environment.

If you go with a Geek ticket — we’ll offer a quiet and all-inclusive Business Lounge where you can meet speakers and partners. Advanced tickets will allow you to attend workshops where you can discuss with speakers the topics you are interested in. Standard tickets will give you access to all the presentations on the main stage, as well as the opportunity to visit our partner stand and start new collaborations.

#4 Rock at the afterparty

Saturday night is going to be unforgettable. We’ve invited Moldova’s legendary rock band, Gindul Mitei, to light up the stage. With a huge setup, special effects, and professional-grade sound, we’re making sure the energy stays high as we celebrate the amazing connections and insights we’ve gathered over two days. Let’s rock together at the MDC afterparty!

See you at Moldova DevCon 2024 on November 1–2!

You at Moldova DevCon 2024

The story of the future told today.

It’s Friday evening. November. Maybe not the most colorful time in Moldova, but there’s something that makes you excited. You finish work a bit earlier because tonight is special. You’re heading to Moldova DevCon (#MDC) — an event built for you, by people just like you.

You make your way to Chisinau Arena. It’s chilly, but you know what’s waiting inside — a warm atmosphere and a cup of hot tea. Parking is easy, and there are no long lines, even with so many people arriving. We’ve made sure everything runs smoothly for you. Yes, we organized it for you.

You pass the registration quickly and paperless. In the hall, you find volunteers who guide you to the Main Stage, where you find a seat. The first impression — wow, they’ve really put in the effort! With your seat secured, you grab a well-deserved coffee or tea and something tasty to eat.

#MDC starts

The WOW effect continues when we light up the Main Stage. We spent months to make you shiver from excitement today. You are having a great Friday! A quick welcome speech, and then the presentations begin. We’ve brought in speakers from 10 countries for this edition — guaranteed, you’ll learn something new. You decide whom to listen to and when to catch up with old and new friends for a cup of something hot or a glass of wine.

Don’t forget to check out the partner booths — they’ve got giveaways and offers that just might change your life.

By 8 pm, the official program wraps up. You can either hang out at the Arena with fellow tech enthusiasts or head home to recharge for tomorrow.

If you’ve got a Geek ticket, the night continues with our Wine&Tech party at the Arena’s Business Lounge.

#MDC continues

The second day you come in the morning and we meet you with coffee, tech talks, and new experiences! We’ll spend the whole day together listening to presentations, attending workshops, and chatting. Relax zones, tons of placintas, and glasses of wine together with stunning presentations on the biggest Arena in Moldova!

Join official TG channel for updates and offers: https://t.me/MDC2024

Check our Agenda and Speakers list — you won’t be bored! The speakers will talk about the hottest topics in tech right now. They’ll cover everything from AI and machine learning to cybersecurity and cloud computing. You’ll hear from local and international pros who are right in the middle of these developments, sharing real-world experiences and actionable tips. Plus, there’s a strong focus on the specific challenges and opportunities developers in Moldova face.

Afterparty

Photo Lev Riseman

At 7 pm, the official #MDC wraps up, but the fun is just beginning. It’s time to celebrate and create memories! Grab a drink — beer, wine, or water — and hit the dance floor. We’ve got a sound setup that’ll blow your mind and body! Gîndul Mîței is performing — just for YOU! And there’s a surprise at the end 😉

Hope you enjoyed the journey that leaves a pleasant aftertaste! But there’s one important thing to mention…

…not going to MDC is OK

Sure, you could skip MDC. You’ll be fine. But when you see all the photos and videos, especially from the afterparty, you might wish you’d been there. And we don’t want you to have that regret (better to regret what you did, not what you didn’t!). So, here’s a promo code ‘igotomdc’ — use it here for a friendly discount and join us!

Final thoughts — let’s talk about those who made this happen.

Partner contribution matters

#MDC budget was always covered by ticket sales only by 50%. This year it’s even less — expenses grew significantly, and ticket prices can’t keep this pace. To cover this we need partners — and they said YES to celebrate those who actually do the digitalization! This year wasn’t an easy one for the tech sector, but these brave companies stood out to help. And my (and hopefully yours) respect and gratitude towards them is enormous. Here is the list of our supporters!

Team

#MDC is our passion project. Every year we have a brave team that spends lots of their time and nerves for you to enjoy this incredible event. You won’t see the majority of them except for the one moment — when we all go on stage for the final bow. And we feel how you bow back — your applause explains WHY we did it. And this is what fills our hearts with love and passion. And we give it back preparing for the next event — the infinite loop of energy that makes this crazy world go round!

Updates: https://t.me/MDC2024

Event details: https://mdc.md/

Tickets: https://iticket.md/event/moldova-devcon-24 (use ‘igotomdc’) promo code

See you at #MDC24!

Navigating the Tech Talent Shortage: Strategies for IT Recruitment Success

In the realm of IT recruitment, the dynamics are in a perpetual state of transformation. With each passing day, new technologies surface, skill prerequisites undergo changes, and the race to secure premier tech talent becomes increasingly fierce. However, one enduring obstacle stands tall: the ever-persistent tech talent shortage. As enterprises grow ever more dependent on technology, the appetite for IT professionals surpasses the available pool. In this article, we embark on a collective journey to delve into the strategies and proven best practices that can empower your organization to effectively navigate the challenges posed by tech talent scarcity.

We’ll build your product from scratch or join the existing team. We’ve hired technically strong engineers who speak your language and respect your time zone. Companies from 20 countries already work with us. We are ISO 9001 and ISO 27001 certified by TUV Austria. — FusionWorks

As a pragmatic and well-organized personality, I adore bullet points or enumerations, so it is much clear about key topics and you may choose what to read (or use diagonal reader mode 👀), if you enjoy or at least try to, these as well, next points will be dedicated to your majesty 🌝.

1. WHAT do you really need? What is your goal? Who are you looking for and what for?

Before you embark on the recruitment journey, it’s crucial to have a clear understanding of your organization’s specific IT needs. Define the skills, experience, and cultural fit you’re looking for in a candidate. By having a precise job description, you’ll attract candidates who are a better match for your requirements, reducing the time spent sifting through resumes.

There are expert-teams that may suggest cost-effective solutions for your challenges, not just “monkey-jobers” that will work on well-described tasks. One of them are our partners from Consulting. Optimize your work, save your money, contact them today.

2. Employer BRANDING

Your organization’s reputation matters. Tech professionals are selective about where they work, and a strong employer brand can be a magnet for top talent. Showcase your company’s values, culture, and commitment to innovation through your website, social media, and employee testimonials. Highlight unique perks and opportunities for growth.

“Words and opinions from the roof are the ones that matter, on documents you may find too many words, but there is the truth.” — Anton Perkin, CEO, FusionWorks

3. Listen to, motivate, and promote your team members

Your current employees can be your best recruitment advocates. Encourage them to refer potential candidates from their professional networks. Employee referral programs tap into a hidden talent pool and foster a sense of engagement and loyalty among your staff. Also when you do have a new position available, try to motivate your team members and promote them — the ones who are dedicated and loyal — these will show better results as they will honor your choice.

4. Collaborate with Educational Institutions

Forge partnerships with universities, coding boot camps, and technical schools. Engaging with these institutions can provide early access to emerging tech talent. Consider offering internships, co-op programs, or sponsoring student projects to identify and nurture future IT professionals.

So far this year, FusionWorks is in the process of completing one internship program in FrontEnd (Hi, Ion!), has finished three internship programs in BackEnd (👋 Vitalie, Mariana, Artur), and this week, it is the beginning of a university practice with nine students (Hello to all of you!), we welcomed and will help with their first-steps-into-practice.

5. Embrace Remote Work and Flexibility

The tech talent you seek may not always be within commuting distance. Embrace remote work options to expand your talent pool geographically. Many IT professionals value flexibility, and offering remote work opportunities can make your organization more attractive.

If for your business model, it is easier to work with freelancers, feel free to reach out to our colleagues from Talents.Tech — they have always the solutions

6. Develop a Continuous Learning Culture

Invest in the growth and development of your current IT team. Provide training, certifications, and opportunities for skill enhancement. A commitment to lifelong learning retains your existing talent and attracts new professionals seeking growth opportunities.

This AUTUMN, FusionWorks prepared an incredible surprize! Stay tuned and you will be one of the first to know it 😮. PS As far as I know, this news will be told from the stage, right at this event. Lucky you, who read till here))

7. Streamline the Recruitment Process

A lengthy and cumbersome recruitment process can turn off top candidates. Streamline your hiring process by reducing unnecessary steps, leveraging technology for initial screenings, and providing prompt feedback to applicants.

8. Stay Informed About Market Trends

The tech industry evolves rapidly. Stay up-to-date with our world’s latest trends, emerging technologies, and competitive salaries. This knowledge will help you make informed decisions and adapt your recruitment strategy accordingly.

The tech talent shortage is a challenge, but it’s not insurmountable. By understanding your needs, building a strong employer brand, collaborating with educational institutions, and embracing flexibility, your organization can successfully navigate this shortage. It’s a journey that requires adaptability, innovation, and a commitment to continuous improvement. With the right strategies in place, you can secure the IT talent your organization needs to thrive in an ever-changing digital landscape.