#What you'll find here

• CTO Log. What really happens in the CTO seat: architecture decisions, hiring, incidents, roadmaps that change mid-quarter, and what I'd do differently.
• Launches. The products I build or lead, why they exist and what problem they solve.
• Signals. Industry news, read with one question in mind: what does this mean for a startup or an SME that has to decide with a small team and little time?

#Who I'm writing for

Founders who have to make technical decisions without being technical, product teams growing faster than their architecture, and other CTOs who want to compare notes.

#How I'll write it

Short, concrete, no fluff. If there's a number, it's one I can stand behind. If something went wrong, I'll say so. And I won't publish anything confidential about the clients I work with: when I talk about a case, it will be with their permission or abstracted enough that it can't be recognised.

I write in English and Spanish. If something here is useful to you, or you disagree, message me on LinkedIn or book a call: the best ideas for a post always come out of a conversation.

That's the job CalendaVibe does.

#What it does

• Booking links connected to Google Calendar and Outlook, so availability is always the real one.
• Google Meet links created for every booking, without copying and pasting anything.
• Stripe payments, so paid sessions are charged at booking time.
• Teams, so a booking can land on whoever is free instead of on one overloaded calendar.

And it's free to get started. You shouldn't need a budget line to stop sending "does Tuesday at 4 work?" emails.

#Why build another scheduling tool

Because the useful part is small and well understood, and the rest is pricing. Most tools put the features a small business needs on day one (payments, a second team member) behind a paid tier. I wanted the opposite: the basics free, done properly.

#How it's built

React on the front end, Node.js and PostgreSQL behind it. Calendar integrations are the hard part of a product like this: time zones, recurring events, permissions and providers that each model availability their own way. That's where most of the engineering went.

#Try it

If you take bookings, try it with a real link this week, and tell me what's missing. I read every message.

The EU's Digital Omnibus on AI, Regulation (EU) 2026/1744, is now in force, and it changes the AI Act's calendar. As summarised by Orrick and other firms:

• High-risk systems listed in Annex III (hiring, credit scoring, education and similar uses) now have until 2 December 2027, instead of 2 August 2026.
• High-risk AI embedded in regulated products (Annex I) moves to 2 August 2028.
• The transparency duties of Article 50, such as telling people they're talking to an AI, still apply from 2 August 2026. Systems already on the market before that date get until 2 December 2026 for the marking of AI-generated content.
• The SME simplifications (lighter technical documentation, proportionate quality management, priority access to sandboxes, lower penalty caps) are extended to a new "small mid-cap" category: companies with fewer than 750 employees and up to €150 million in turnover.

#Why it matters for startups and SMEs

The delay is good news, but it's a delay, not a cancellation. The requirements are the same; only the dates moved. Two traps I see coming:

1. "We have until 2027" becomes "we'll think about it in 2027". If your product scores people, screens CVs or decides on credit, the hard part isn't the paperwork. It's the data lineage, the logging and the human oversight that have to be designed into the system. Retrofitting that into a product that has shipped for a year is far more expensive than building it in now.
2. Forgetting what already applies. If you have a chatbot, an AI assistant or anything that generates content for users, transparency is already your problem today, not in 2027.

#What I'd do this quarter

• Make an inventory. List every place your product uses AI and classify each one: prohibited, high-risk, transparency-only or minimal. It's usually a one-afternoon exercise and it changes the conversation.
• Fix the cheap transparency items now. A clear "you're talking to an AI assistant" notice and labelled AI-generated content cost little and are already required.
• If anything is high-risk, design for it in the next roadmap. Logging of inputs and decisions, a human override, and documentation of your training and evaluation data. Treat it as architecture, not compliance.
• Check whether you qualify as an SME or small mid-cap. The simplified regime is real money saved.

The extra time is useful only if you spend it building the system you'll need anyway.

This is a CTO's reading of public summaries, not legal advice. For your specific case, talk to a lawyer who works on the AI Act.

#Four options, four different jobs

• A senior developer writes and ships code. Great when the product is clear and the risk is execution.
• An agency or freelancers build a defined scope. Great when you know exactly what to build and someone inside can judge the result.
• A fractional CTO owns technical strategy and the big decisions a few days a month: architecture, vendors, hiring, the roadmap. Great when the decisions are high-stakes but don't fill a full-time role yet.
• A full-time CTO does all of the above every day, and builds and leads the team. Necessary when technology is the business and the team is big enough to need daily leadership.

#Signs you need senior technical leadership now

• You're about to make a decision that's expensive to reverse: a platform rewrite, a cloud migration, a core vendor, your first engineering hires.
• Your developers or your agency are making architecture decisions by default, and nobody on the business side can tell if they're good ones.
• Delivery has slowed down and nobody can explain why in plain words.
• Investors, a big client or an auditor are starting to ask technical due-diligence questions.
• Cloud or vendor costs are growing faster than revenue.

#Signs a fractional CTO is enough

• The big decisions come in waves (a launch, a migration, a funding round), not every day.
• You have, or will soon have, someone who can execute: a lead developer, a small team or a partner.
• You can't yet justify a full executive salary, or you don't want to hire one before you know what the role really needs.

#Signs you need a full-time CTO

• Technology is your core product and differentiation, not a supporting function.
• The engineering team is big enough that it needs daily leadership, career paths and hiring at a steady pace.
• Technical decisions happen every day and waiting a few days for an answer is costly.

A good fractional engagement often ends exactly there: with the architecture in order, the team hired and the profile of the full-time CTO you need written down.

#A simple test

Write down the five most important technical decisions you'll make in the next six months. If you can't write the list, or you can't say who will make each one, you need help with technical leadership, whatever form it takes.

#Week 1: listen before touching anything

• Founders and leadership: where the business is going in the next 12 months, and which technical problem keeps them up at night.
• The team, one by one: what slows them down, what they'd fix first, what they're afraid to touch.
• Customers' view: the top support tickets and the complaints sales hears. They tell you where quality really hurts.

Output: a one-page summary of goals, pains and constraints, shared back with everyone I spoke to.

#Week 2: the technical audit

• Architecture: how the main pieces talk to each other, where the data lives, what's a single point of failure.
• Code and delivery: how a change gets from a laptop to production, how long it takes and how often it breaks.
• Cloud and costs: what runs where, who has access and what each part costs.
• Vendors and contracts: what you depend on and how hard it would be to leave.
• Security basics: secrets, backups, access, and whether anyone has ever restored a backup.

I'm not grading the team. Most problems I find are reasonable decisions that outlived their context.

#Week 3: the roadmap

Every finding goes into one of three buckets:

1. Fix now: risks that could hurt the business soon (data loss, security holes, a fragile release process).
2. Build next: the changes that unblock the product roadmap.
3. Leave alone: things that look ugly but aren't worth the time today. Saying this out loud is half the value.

Each item gets an owner, an effort estimate and the business outcome it serves. If I can't link an item to an outcome, it doesn't go on the roadmap.

#Week 4: start executing, together

• Pick one or two quick wins the team can ship in days, to build trust in the plan.
• Agree on the working rhythm: when I'm available, how decisions get made and documented, what gets reviewed.
• Start the first structural item hands-on, alongside the team.

#The goal

From day one the goal is a team that doesn't depend on me. Every decision gets written down, every standard gets automated where possible and every hire raises the bar. If the company still needs me in the same way after a year, I haven't done the job well.

#Microservices are an organisational tool

Their main benefit is letting many teams deploy independently without stepping on each other. If you have one team of five, you don't have that problem. What you do get is the cost: network calls instead of function calls, distributed transactions, more infrastructure, more pipelines, harder debugging and more on-call surface.

For a small team that's still searching for product-market fit, that cost is paid in the one currency it can't afford: speed of change.

#What "modular" means in practice

A monolith becomes a mess when everything can call everything. A modular monolith sets boundaries from day one:

• Modules by business capability (billing, catalogue, users), not by technical layer.
• Each module owns its data. Other modules don't read its tables; they call its public interface.
• Explicit public interfaces. Anything not exported is private, and a lint rule or architecture test enforces it.
• Internal events for side effects. "Order paid" is published inside the process; whoever cares subscribes. The day that becomes a message on a broker, the code barely changes.

#The signals that it's time to split a module out

• A module needs to scale very differently from the rest (a heavy background job, a spike-prone API).
• Several teams are blocked on each other's releases in the same codebase.
• A module has different requirements for availability, security or compliance.
• Deploys are slow or risky because of the size of the whole, and modular builds no longer help.

None of those is "it's 2026 and microservices are what serious companies do".

#How to split without a rewrite

When a module earns its own service, the boundaries are already there: it owns its data, it has a public interface and it communicates through events. Extracting it is moving code and replacing in-process calls with network calls, not a six-month redesign. That's the whole point of starting modular: making the expensive decision later, when you have the information to make it well.

#What it does

Closevibe automates sales and customer-service conversations for e-commerce businesses across the channels their customers already use: WhatsApp, Instagram, Messenger and email. It answers with the shop's own knowledge, detects what the customer wants and keeps the conversation going in real time.

You can see it working on this site: the chat assistant in the corner is powered by Closevibe.

#How it's built

I architected the platform from scratch. The pieces that matter most:

• Multi-tenant from day one. Every shop's data, knowledge and conversations are isolated.
• RAG-based agents. Answers are grounded in each business's own content, retrieved with semantic vector search on PostgreSQL with pgvector, instead of relying on what a model happens to remember.
• Intent detection and real-time orchestration, so the system knows whether it's facing a pre-sale question, an order issue or something a human should take over.
• Channel integrations through the Meta Business APIs (WhatsApp, Instagram, Messenger) and email.
• The stack: Python and FastAPI, React, PostgreSQL with pgvector, Docker on GCP and Railway.

#What I learned building it

The model is the easy part. The hard parts are the boring ones: getting the right context into each answer, knowing when not to answer, handing over to a person cleanly and making every channel behave the same despite each API having its own rules. That's where most of our engineering time goes, and it's what makes the difference between a demo and something a shop trusts with its customers.

#Try it

If you sell online and your team spends its day answering the same questions, take a look.