2025-12-15 19:09:59
Let's be honest: most marketing budgets are fiction dressed up as spreadsheets.
You allocated funds in January 2025 based on optimistic projections, a competitor's case study that conveniently left out their $500K ad spend, and whatever your CEO read on a flight. Now it's December, and you're staring at a budget that bears zero resemblance to where money actually went.
I've watched this play out dozens of times. The paid social budget that doubled because "TikTok is where our audience is" (spoiler: they weren't). The content marketing line item that got raided for emergency campaign spending in March. The marketing automation platform you're paying $2,400/month for that exactly two people know how to use.
Here's the thing: Q1 2026 doesn't have to be a repeat performance. But you need to audit what actually happened in 2025 before you start allocating dollars for next quarter. Not the sanitized version you'll present to leadership. The real version.
Pull every marketing expense from January through November 2025. Every single one.
Your accounting software, credit card statements, subscription emails—all of it. Because the official budget spreadsheet is missing at least 20% of actual spend. I guarantee it.
That designer you hired on Fibre for "just one project"? In there. The three different AI writing tools your team signed up for because nobody checked if someone else already had a subscription? Count them. The conference registration that somehow came out of the events budget even though it was clearly professional development? Yeah, that too.
Create four categories:
Fixed costs: Platforms, tools, and subscriptions that bill automatically. These are your HubSpot, Semrush, Adobe subscriptions. The stuff that hits your card whether you use it or not.
Variable costs: Ad spend, freelancers, agencies. The expenses that theoretically flex based on activity and results.
Hidden costs: This is where it gets interesting. Internal time (your content manager spending 15 hours/week on social media), training, failed experiments you wrote off mid-year, that rebrand that "only" cost $8K because you did it in-house.
Zombie costs: My personal favorite. Subscriptions you forgot existed. Tools the person who left in April was using. That premium LinkedIn seat for the intern who finished in August. One audit I ran found $14,000 in annual zombie spend. Just... haunting the budget.
Now compare this reality to your January 2025 budget.
The gaps tell you everything. If paid search was allocated $50K but you actually spent $73K, that's not a math error—it's a signal about where you saw results (or got desperate).
Forget ROAS for a minute. Seriously.
I want you to calculate true cost per channel, including all the hidden expenses everyone ignores in the pretty dashboard.
Content marketing isn't just writer fees. It's:
When you add it all up, that blog post that "only cost $400" actually cost $1,100. Still worth it if it's driving pipeline, but you need the real number.
Paid social isn't just ad spend:
One company I worked with thought their paid social CPL was $43. Real number including all costs? $67. Still profitable for them, but that's a 56% difference in understanding unit economics.
Do this for every channel. Email, SEO, events, partnerships, influencer campaigns, that podcast you started and abandoned after six episodes.
The goal isn't to depress yourself (though it might). It's to understand true cost per result before you allocate another dollar.
This is where most budget audits fall apart.
You've got costs figured out. Great. Now you need to connect them to actual business outcomes, not vanity metrics that look good in a quarterly review.
Ignore impressions. Ignore engagement rate. Ignore "brand awareness lift" unless you've got a legitimate study with a control group (you don't).
What matters:
Pull your CRM data. Filter by source. Look at opportunities created and closed revenue by marketing channel.
Now here's where it gets messy: attribution is still kind of a disaster in 2025. Multi-touch attribution sounds great until you realize it's giving partial credit to that display ad someone saw three months ago while scrolling through a recipe blog. First-touch over-credits top-of-funnel. Last-touch over-credits bottom-of-funnel.
I use a blend:
It's not perfect. But it's more honest than pretending your attribution model is capturing reality.
Look for surprises. In 2025, I've seen:
Your data will tell you where to double down and what to kill. If you listen to it.
Every budget has fat. Time to trim it.
Start with zombie subscriptions. Cancel anything that hasn't been logged into in 60+ days. If someone complains, you can always reactivate it. Nobody will complain.
Next: tools with overlapping functionality. You don't need three social media scheduling platforms, four SEO tools that do the same keyword research, and two email marketing systems because "different teams prefer different interfaces." Pick one per category. Make people adapt.
The savings here are usually 15-25% of your software stack. For a $500K budget, that's $75-125K back in play.
Now the harder cuts: channels that aren't working.
I know you spent six months getting that TikTok strategy approved. I know your CEO is convinced LinkedIn video is the future. I know the agency promised the display campaign just needs "a bit more time to optimize."
Cut it anyway.
If a channel hasn't shown meaningful results in 6+ months of legitimate effort, it's not suddenly going to pop in month seven. Maybe your audience isn't there. Maybe your offer doesn't work in that format. Maybe the platform changed and your playbook is outdated.
Doesn't matter. Cut it.
Exception: early-stage experiments. If you're genuinely testing something new (like how AI-powered content performed in 2025), give it a fair shot. But "testing" for 18 months isn't testing. It's hoping.
Create a "stop doing" list:
This will be uncomfortable. Someone's pet project is on this list. Possibly yours.
Cut it anyway. Q1 2026 budget space is earned by killing what didn't work in 2025.
You've got your real costs, your real results, and you've cut the dead weight. Now you can actually allocate Q1 2026 resources based on something resembling reality.
Start with your proven performers. The channels that drove pipeline at acceptable CAC get first priority. If SEO generated 40% of your opportunities, it should get more than 8% of your budget.
I use a simple framework:
60% to proven channels: What worked in 2025 gets the majority of resources. Scale what's working before you go hunting for the next shiny thing.
25% to optimization: Take your proven channels and make them better. Better creative, better targeting, better conversion paths, better follow-up. The ROI on optimization usually beats the ROI on new channel experiments.
15% to experiments: Now you can play. Test new channels, new formats, new approaches. But with clear success metrics and kill criteria. If it's not working by end of Q1, it doesn't get Q2 budget.
For Q1 specifically, factor in seasonality. If you're B2B, Q1 is when budgets reset and buying cycles restart. If you're e-commerce, you're recovering from holiday hangovers and dealing with January return rates.
Look at Q1 2025 performance by channel. Some things work better in Q1 than other quarters. Adjust accordingly.
Here's what nobody tells you about budget planning: something will absolutely go sideways in Q1.
A competitor will launch a product that changes your positioning. Google will update their algorithm and tank your traffic. iOS will change something and break your attribution. Your best channel will suddenly get expensive because everyone else discovered it too.
Hold back 10-15% of your budget as a flexibility reserve. Not for random ideas that pop up in meetings. For strategic responses to market changes.
Create decision criteria for deploying reserve budget:
Document these criteria now. Because in February when someone wants to spend $20K on an "urgent opportunity," you'll need a framework for deciding if it's actually urgent or just loud.
Your Q1 2026 budget isn't a contract with the universe. It's a hypothesis you're testing.
Set up weekly dashboard reviews. Not the pretty ones for executives. The real ones with:
This takes 30 minutes a week. It's how you catch problems early instead of discovering in March that you're 40% over budget on paid search and have nothing to show for it.
Monthly, do deeper reviews:
The best budget allocations I've seen get adjusted 3-4 times per quarter based on performance data. The worst ones get set in January and ignored until someone asks why the numbers are off.
Before you finalize anything:
✓ Actual 2025 spend documented (including hidden costs)
✓ True cost per channel calculated
✓ Results tied to business outcomes, not vanity metrics
✓ Zombie subscriptions canceled
✓ Underperforming channels cut
✓ Budget allocated 60/25/15 to proven/optimize/experiment
✓ 10-15% flexibility reserve established
✓ Weekly tracking dashboard set up
✓ Monthly review calendar blocked
✓ Kill criteria defined for new experiments
One more thing: share the real numbers with your team.
Not the sanitized version. The actual costs, actual results, and actual reasoning behind Q1 allocation decisions. When people understand why budget decisions were made, they stop fighting for pet projects and start optimizing for outcomes.
Your 2025 budget probably didn't survive contact with reality. That's fine. Most don't.
But your Q1 2026 budget can be different. If you're willing to audit what actually happened, cut what didn't work, and allocate based on evidence instead of optimism.
The spreadsheet won't be as pretty. But the results will be better.
And honestly? That's the only number that matters.
2025-12-15 19:07:59
**
**
A few months ago, I found myself doing the same thing over and over again.
Open dbt Cloud.
Click through models.
Check lineage.
Open docs.
Switch projects.
Repeat.
None of this was bad. dbt Cloud does its job well. But the more I worked across different environments — local setups, on-prem systems, restricted networks — the more friction I felt. Not enough to complain loudly, but enough that it stayed in the back of my mind.
The gap I kept running into
Most dbt workflows eventually revolve around the same questions:
What models exist here?
How does this model depend on others?
What changed recently?
Can I quickly inspect the SQL behind this?
What happened in the last run?
You don’t need a lot of bells and whistles to answer those questions. You need visibility, clarity, and speed.
But when you’re not fully cloud-native — or when you care about running things locally, on-prem, or inside constrained environments — options thin out quickly. You either stitch together scripts, or you accept that some things will always live behind a hosted service.
That’s fine for many teams. It just wasn’t fine for all of my use cases.
So I started experimenting
At first, it was just curiosity.
What if dbt artifacts themselves — manifest.json, run_results.json, catalog.json—were enough to power a clean UI?
What if you didn’t need a remote service to explore your project?
What if switching between dbt projects felt as lightweight as switching folders?
I started hacking together a small UI that simply read what dbt already produces. No magic. No extra metadata. Just visibility.
That experiment slowly grew into something more intentional.
I ended up building dbt-Workbench: a self-hosted, open-source UI for dbt projects.
Not as a replacement for dbt Cloud, but as an alternative for situations where you want:
Local or on-prem setups
No vendor lock-in
Multiple dbt projects in one place
Direct access to compiled SQL and artifacts
A UI that stays close to how dbt actually works
The idea was simple:
Let dbt be dbt. Just make it easier to see what’s going on.
What it focuses on (and what it doesn’t)
dbt-Workbench isn’t trying to reinvent dbt. It leans on what dbt already does well.
Become a member
It gives you:
Model browsing and documentation
Lineage visualization
A SQL workspace that shows compiled SQL side by side with model code
Run history and logs
Multi-project support with proper isolation
A plugin-friendly architecture for extensions
What it doesn’t try to do:
Abstract dbt away
Hide how dbt works
Replace your existing workflows overnight
You can run it locally with Docker, point it at your dbt artifacts, and see value almost immediately.
This kind of tool only makes sense if it’s transparent.
Air-gapped environments
Strict security policies
Custom dbt setups
Unusual warehouse configurations
Open source makes it possible to adapt the UI to those realities instead of forcing everything into one mold.
It also keeps the project honest. If something feels wrong or unnecessary, it shows up quickly when other engineers look at it.
dbt-Workbench is very much a work in progress. Some parts are solid, others are actively evolving. That’s intentional.
I’d rather build it in the open, shaped by real feedback, than polish something in isolation and hope it fits.
If you’re curious, the project lives here:
https://github.com/rezer-bleede/dbt-Workbench
No signup. No sales pitch. Just code.
Most of us don’t need more tools.
We need tools that quietly reduce friction.
dbt-Workbench is my attempt at one of those. If it resonates, great. If it sparks ideas or critiques, even better.
That’s usually how the best tools start anyway.
Connect with Me on LinkedIn
I’d love to keep the conversation going. If you found this article insightful or have thoughts, experiences, and ideas to share, let’s connect on LinkedIn!
I’m always eager to engage with fellow professionals and enthusiasts in the field.
2025-12-15 19:07:29
¿Alguna vez has entrado a un proyecto Legacy (o incluso uno nuevo mal configurado), intentas compilar y tu consola se tiñe de rojo con errores tipo The type or namespace name 'X' could not be found? 😵 O peor aún, ¿te ha tocado ese escenario donde el proyecto busca una DLL en una carpeta de red Z:\Librerias que solo existía en la máquina del desarrollador que renunció hace dos años?
Si te ha pasado, sabes la frustración de perder horas (o días) solo intentando levantar el entorno. A menudo, el problema no es el código C#, es la gestión de dependencias. Hoy vamos a arreglar esto de raíz, entendiendo cómo consumir librerías de forma profesional, segura y escalable.
Imagina que NuGet es el Amazon o Mercado Libre de .NET. Tú no fabricas cada tornillo de tu mueble; los pides a la tienda.
Muchos desarrolladores creen que cuando ejecutan dotnet restore, las DLLs "mágicamente" aparecen en su proyecto. Entender el flujo real es vital para saber qué está pasando por detrás:
.csproj) pide Newtonsoft.Json v13.0.1.%userprofile%\.nuget\packages en Windows o ~/.nuget/packages en Linux/Mac). No se guardan dentro de tu proyecto.
¿Por qué importa esto? Porque optimiza el espacio. Si tienes 10 proyectos usando la misma librería, solo se descarga una vez en tu disco duro.
Antes de escribir una sola línea de configuración, debes entender cómo "piensa" NuGet. Cuando ejecutas un restore, no solo mira tu proyecto. NuGet combina configuraciones en cascada siguiendo una jerarquía estricta:
%appdata%\NuGet\NuGet.Config) y suele acumular mucha "basura digital" con el tiempo.
Aquí nace el famoso meme. Imagina que tú tienes configurado un feed privado en tu Nivel Usuario porque trabajas en varios proyectos de la empresa. Creas un proyecto nuevo y compila perfecto. Tu compañero clona el repositorio, intenta compilar y... error.
¿Por qué? Porque tu proyecto está dependiendo de una configuración "invisible" que vive solo en tu usuario. Para tu compañero, ese feed no existe.
¿Cómo detecto esto? No adivines. Sitúate en la carpeta de tu solución y ejecuta el siguiente comando:
dotnet nuget list source
Este comando te mostrará la lista final y combinada de todos los orígenes que NuGet está usando realmente en esa carpeta. Si ves rutas que no reconoces o servidores apagados, es culpa de la herencia.
¿Cómo rompemos esa cadena de herencia tóxica y arreglamos el proyecto para todos? Creando un archivo NuGet.config explícito en la raíz de tu solución.
Aquí tienes una configuración que cubre los escenarios reales:
<configuration>
<packageSources>
<!-- ¡IMPORTANTE! <clear/> elimina toda la "basura" heredada del usuario o máquina -->
<clear />
<!-- 1. El estándar público -->
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
<!-- 2. Nube Privada (GitHub Packages, Azure, AWS) -->
<!-- Ideal para equipos modernos y CI/CD -->
<add key="GitHubFeed" value="https://nuget.pkg.github.com/mi-empresa/index.json" />
<!-- 3. Servidor NuGet Local (BaGet o similar) -->
<add key="BadGetFeed" value="http://servidor-interno:5555/v3/index.json" />
<!-- 4. Carpeta Local en Servidor On-Premise -->
<add key="OnPremiseFeed" value="./LibreriasAntiguas" />
</packageSources>
<!-- Puedes deshabilitar fuentes temporalmente sin borrar la línea -->
<disabledPackageSources>
<add key="OnPremiseFeed" value="true" />
</disabledPackageSources>
<packageSourceCredentials>
<!-- Autenticación Segura para feeds privados (Usa variables de entorno) -->
<GitHubFeed>
<add key="Username" value="DevUser" />
<add key="ClearTextPassword" value="%GITHUB_TOKEN%" />
</GitHubFeed>
</packageSourceCredentials>
</configuration>
Beneficios de configurar esto:
<clear />, proteges tu proyecto de configuraciones globales rotas.git clone y dotnet restore. No necesita configurar nada manual.Aquí es donde muchos desarrolladores fallan. Si tienes configurado nuget.org y GitHubFeed, y ambos tienen un package llamado Newtonsoft.Json... ¿cuál se descarga?
NuGet actua "al primero que responda". Esto es peligroso por dos razones:
nuget.org con el mismo nombre que tu paquete privado interno (ej: MiBanco.Core), ¡tu proyecto podría descargar el package del atacante sin darte cuenta! 🚨
Para solucionar el caos de prioridad y asegurar qué bajamos, tenemos dos herramientas clave:
Es básicamente decirle a NuGet: "Los paquetes de Microsoft búscalos en la tienda pública, y los paquetes de mi empresa SOLO búscalos en mis servidores".
<configuration>
<!-- ... sección packageSources definida arriba ... -->
<!-- AQUÍ ESTÁ LA MAGIA -->
<packageSourceMapping>
<!-- Regla 1: Mis librerías Core van a GitHub Packages -->
<packageSource key="GitHubFeed">
<package pattern="MyCompany.Core.*" />
<package pattern="MyCompany.Auth.*" />
</packageSource>
<!-- Regla 2: Librerías internas van al Server NuGet Privado -->
<packageSource key="BadGetFeed">
<package pattern="InternalTools.*" />
</packageSource>
<!-- Regla 3: Componentes viejos van a la carpeta local -->
<packageSource key="OnPremiseFeed">
<package pattern="OldComponent.WinForms.*" />
</packageSource>
<!-- Regla 4: Todo lo demás (Microsoft, System, etc.), búscalo en nuget.org -->
<packageSource key="nuget.org">
<package pattern="*" />
</packageSource>
</packageSourceMapping>
</configuration>
A veces descargas el paquete correcto, pero tiene agujeros de seguridad conocidos. No necesitas herramientas caras; .NET lo trae nativo.
Ejecuta esto regularmente o en tu CI/CD:
dotnet list package --vulnerable
Te dirá qué paquetes tienen riesgos (Crítico, alto o moderado) y a qué versión segura actualizar.
Si trabajas en una solución con muchos servicios, seguro te ha pasado esto:
Newtonsoft.Json v11.Newtonsoft.Json v13.Newtonsoft.Json v9.¡Es un caos de versiones! 🤯
Para solucionar esto en proyectos modernos, usamos Central Package Management (CPM). En lugar de definir la versión en cada .csproj, las centralizamos.
<Project>
<PropertyGroup>
<!-- Activar CPM -->
<ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
</PropertyGroup>
<ItemGroup>
<!-- Aquí defines la versión UNA SOLA VEZ para toda la solución -->
<PackageVersion Include="Newtonsoft.Json" Version="13.0.3" />
<PackageVersion Include="Microsoft.EntityFrameworkCore" Version="8.0.0" />
</ItemGroup>
</Project>
En tus proyectos individuales, ya no pones la versión, solo el nombre:
<!-- En .csproj -->
<ItemGroup>
<!-- Sin versión porque ya lo toma de Directory.Packages.props -->
<PackageReference Include="Newtonsoft.Json" />
</ItemGroup>
Una vez que has creado o ajustado tu archivo NuGet.config con los sources y el mapping, ve a tu terminal y ejecuta:
# Limpia cachés locales para asegurar que las reglas nuevas apliquen
dotnet nuget locals all --clear
# Restaura usando la nueva configuración
dotnet restore
No dejes que las dependencias te controlen a ti. ¡Toma el control de tus paquetes!
¡Happy coding! 🚀
2025-12-15 18:58:01
Elevate your Data from Spreadsheet to Strategy
In the world of finance, investment banking, and professional data analysis, a raw Excel spreadsheet is not enough. Your data needs to be transparent and fully contextualized. This is where footnotes come in.
Footnotes provide the essential context-clarifying assumptions, detailing methodologies, and citing sources-that turn a confusing table of numbers into a reliable, decision-making document.
However, unlike Microsoft Word, Excel does not have a simple “Insert Footnote” button. This guide breaks down five powerful workarounds you can use to add professional, clean, and reliable footnotes to any Excel model.
Footnotes are not just for academic papers; they are vital business tools that:
Explain Your Assumptions Clearly
When you use estimates or assumptions in your calculations, footnotes explain the logic behind them. This helps others understand why certain numbers were chosen.
Example: “The 5% growth rate is calculated based on the average performance of the last three years.”
Provide Helpful Context
Sometimes numbers look unusual or unexpected. Footnotes allow you to explain these situations so readers do not get confused.
Example: “The increase in Q3 is due to a one-time asset sale and is not part of regular revenue.”
Show Data Sources
Footnotes help you mention where the data comes from, such as reports, websites, or databases. This increases trust and makes your work more reliable.
Example: “Data sourced from the company’s audited financial statements.”
Improve Communication and Reduce Errors
By adding footnotes, you make sure everyone reading your Excel file understands the data the same way. This reduces misunderstandings and helps stakeholders make better decisions.
Here are five distinct strategies, from simple and internal to complex and polished, that you can use to incorporate footnotes into your work.
Method 1: The Quick-and-Easy Approach-Using Notes (Comments)
The built-in Notes feature is the fastest way to attach explanatory text directly to a specific cell without cluttering your view.
Step-by-Step Guide:
Pros:
Cons:
Method 2: The Visible Approach- Adding a Dedicated Column
If you need your footnotes to be visible at all times, including on printed reports, creating a separate, designated column is an excellent solution.
Step-by-Step Guide
Pros:
Cons
Method 3: The Clutter-Free Approach - Using Hyperlinks
This method is ideal for very large, complex workbooks where you need to keep the main sheet impeccably clean but provide deep references.
Step-by-Step Guide
Pros:
Cons:
Method 4: The Polished Look-Using Text Boxes
For a professional, static visual that mimics a report’s true footnote section, you can use a Text Box to hold all your compiled notes, separate from the Excel grid itself.
Step-by-Step Guide
Pros:
Cons:
Method 5: The General Disclaimer-Using the Header/Footer
This method is best used for non-cell-specific notes, like legal disclaimers, confidential stamps, or general source attribution that applies to the entire page.
Step-by-Step Guide
Pros:
Cons:
Best Practices for Consistent Footnoting
To maintain a truly professional model, with these simple rules, regardless of which method you choose:
You have just spent hours ensuring your Excel model is flawless: every formula is checked, every assumption is noted with a footnote, and your data is perfectly clean. But what happens next?
The Critical step-taking that organized data and turning it into a polished presentation is often biggest task. You risk losing the clarity and context you built in Excel when you manually transfer data into slides.
Introducing MagicSlides: MagicSlides.app is an AI Presentation Maker that acts as the final bridge, instantly converting your detailed financial analysis, research papers, or reports into a stunning, executive-ready Google Slides deck.
Your data is ready. Your insights are clear. Don’t let manual slide design dilute your hard work.
Use MagicSlides to instantly transform your next technical report into a powerful presentation and ensure your message lands with maximum impact.
Excel is super standard for data analysis, but true professionalism in finance and reporting requires more than just accurate calculations-it demands crystal-clear communication.
Since Excel lacks a built-in footnote function, utilising these five methods is essential for maintaining the integrity, context, and credibility of your work.
Choose the method that best fits your workflow, with the best practices for consistency, and ensure that every number on your spreadsheet tells a complete story.
Q 1: Why does not Excel have a footnote feature?
Excel is for data calculation, not formal document layout.
Q 2:which methods is best for printing?
The Dedicated Column or Header/Footer methods print most reliably.
Q 3: If I move a row, will my comment/note move with it?
Yes, Notes(comments) are directly attached to the cell object and will follow the cell.
2025-12-15 18:49:31
Text to video tools sound exciting on paper. Type a prompt, get a video, move on. In reality, most developers and product teams want to know one thing. Does it actually help in real work?
I decided to test a text to video AI tool inside an actual workflow. Not a demo. Not a one off experiment. A real use case with deadlines, revisions, and feedback.
This post shares what worked, what did not, and where this type of tool fits today.
I often need short videos. Product demos, landing page previews, onboarding clips, and quick explainers for internal teams. Traditional video creation takes time. Scripts, screen recordings, edits, exports. It adds up fast.
I wanted something that could help me:
• Create fast visual drafts
• Test ideas before committing to production
• Support non designers on the team
• Reduce back and forth during early stages
That is where text to video AI looked promising.
I kept the setup simple and close to how most teams work.
Step one was writing a rough script. Nothing polished. Just clear sentences explaining a feature or flow.
Step two was generating short video clips from those prompts. I tested different tones. Product focused. Neutral. Slightly creative.
Step three was placing the output into real contexts. A landing page draft. A product walkthrough. An internal demo deck.
This helped me judge the tool based on usefulness, not novelty.
The biggest win was speed. I could turn an idea into a visual in minutes. That alone made it useful during early planning.
Another strong point was clarity. The videos helped explain concepts that were hard to describe with text alone. This was helpful for async communication and early stakeholder reviews.
I also noticed that the tool worked best when prompts were clear and structured. Simple language produced better results than vague descriptions.
During this test, I explored a few platforms, including this text to video option: Kling 2.5 Turbo. It handled short, focused prompts well and fit naturally into quick iteration cycles.
Text to video AI is not a replacement for real video production. At least not yet.
Fine control is limited. You cannot easily tweak small details the way you would in a video editor. If something feels slightly off, you often need to regenerate instead of adjusting.
Consistency can also be a challenge. When you need multiple clips that look and feel the same, it takes effort to guide the tool with careful prompts.
This means the output works best as a draft or supporting asset, not a final polished video.
This tool was most useful for:
• Early stage demos
• Internal presentations
• Product concept previews
• Quick onboarding explanations
It helped non technical teammates understand features faster. It also reduced the pressure on designers and video editors during early phases.
Once the direction was clear, we still moved to traditional tools for final assets.
Based on this test, here are a few practical tips.
Start with short videos. Thirty to sixty seconds works best.
Write prompts like instructions, not marketing copy.
Test videos inside real layouts. Context matters.
Use it early. Do not wait until the final stage.
Treat the output as a draft, not a finished product.
Text to video AI is most useful when you treat it as a thinking tool, not a shortcut to final content. It helps you explore ideas, explain flows, and move faster during planning.
For developers and product teams, that can be enough to justify using it. Not because it replaces anything, but because it helps you decide what to build next with more clarity.
If you are curious, try it inside a real workflow. That is where its strengths and limits become clear.
References:
https://dev.to/alifar/automating-text-to-video-pipelines-with-sora-2-and-n8n-lh0
https://workspace.google.com/resources/text-to-video/
2025-12-15 18:49:01
This is the first part of my journey to creating my SaaS AppReviews
For a long time, app reviews lived in a weird place for me.
I knew they mattered. I knew they were important. I’ve been building Android apps for more than ten years, and I care a lot about product quality and user experience. Reviews are one of the rare places where users tell you, very directly, what they think.
And yet, they were never really part of my day-to-day work.
At work, reviews were something you checked “from time to time”. Or when something went wrong. Or when someone remembered. Which usually meant opening App Store Connect, then Google Play Console, logging in, clicking around, scrolling, trying to get a sense of what happened since the last time.
Most of the time, it felt like a chore.
The real trigger for AppReviews came from a very practical need at work. We wanted to put some basic checks in place around user reviews. Nothing fancy. We didn’t want dashboards, charts, or weekly reports.
We just wanted to know when a new review came in.
Ideally, it should show up in Slack. Same place as deploy notifications, CI messages, and alerts. Somewhere we already look all day. Or a different channel.
When we started looking at existing tools, it felt like everything was either too much or too expensive. Some solutions are clearly built for large companies with dedicated teams handling reviews and customer feedback. They’re powerful, but also overkill if all you want is a simple signal.
For what we needed, the cost and complexity didn’t really make sense.
So the alternative was manual checking.
And that’s where things start to break down.
Doing it manually is annoying, but worse than that, it’s easy to forget. You tell yourself “I’ll check later”. Later becomes tomorrow. Tomorrow becomes next week. Suddenly, you’re reading a review from seven days ago.
By then, the moment is gone.
That part bothered me more than I expected.
A user who leaves a bad review is often still engaged. They’re annoyed, but they cared enough to write something. If you reply quickly, you can clarify, ask questions, explain, sometimes even fix the issue before it turns into something bigger.
Replying days later doesn’t have the same effect. It feels distant. Sometimes pointless.
Missed replies aren’t just about ratings. They’re missed chances to understand what actually happened. Missed context. Missed feedback that could have helped avoid the same issue for the next user.
After seeing this pattern repeat a few times, I did what I usually do when something annoys me enough: I hacked together a script.
The first version was ugly. No UI. No configuration screen. It just fetched reviews and posted a message in Slack when something new appeared.
That was it.
And yet, the impact was immediate.
Reviews stopped being something you had to remember to check. They just showed up. Someone would notice a message in Slack and say “Oh, I saw that one” or “That explains the support ticket we got yesterday”.
Sometimes it would start a conversation. Sometimes it would lead to a quick reply. Sometimes it would just sit there, but at least it was visible.
It felt… healthier.
What surprised me was how small the change was, compared to the effect it had. We didn’t analyze anything. We didn’t optimize. We just removed friction.
That’s when I realized the core problem wasn’t access to reviews. Anyone can access them. The problem is that they live in places you have to actively go to, and anything that requires a recurring manual action will eventually be delayed.
Around the same time, I noticed I was doing the exact same thing on my own projects.
I’d ship something, feel good about it, then think “I should check the reviews”. Sometimes I would. Sometimes I wouldn’t. Sometimes I’d discover feedback way too late and think “I wish I had seen this earlier”.
Same pattern. Different context.
That’s when the idea of turning that script into something more serious started to feel obvious.
At first, I didn’t think of it as a product. It was more like “this should exist”. Something simple, affordable, and focused. Something that doesn’t try to do everything, but does one thing well: make sure reviews reach you, without effort.
Once I started building it properly, new questions came up.
If you centralize reviews, how do you avoid creating another place people stop checking? If you have dozens of reviews, how do you quickly understand what’s going on without reading everything?
I’ve always been more interested in reducing noise than adding features. Most tools fail not because they don’t do enough, but because they do too much. I didn’t want AppReviews to become another dashboard people open once and forget.
So the focus stayed very narrow: visibility, timeliness, and context.
Everything else was secondary.
What I found interesting is that once reviews are always visible, your relationship with them changes. They stop being something slightly stressful you avoid, and become part of the feedback loop of the product.
You don’t “check reviews” anymore. You react to them.
That shift is small, but it matters.
At some point, this side project started to take more shape. Nights, weekends, small iterations. A lot of decisions about what not to build. A lot of resisting the temptation to add features just because I could.
I wasn’t trying to build the ultimate review platform. I was trying to fix a very specific, very human problem I kept running into.
That moment where you think: “I should check the reviews.”
In the next post, I’ll talk about how I decided what AppReviews should focus on, and why cutting features turned out to be one of the most important parts of the project.