Blog
Why we started a blog, and what you will find in it.
In short. We are starting an engineering blog to write down what we learn designing, building, and running digital products. We will only write about what we do every day —Adobe Experience Manager, architecture, cloud, technical audits, distributed talent, product, and technical SEO— with the answer first, our own examples, sources, dates, and a named author.
Why a blog, and why now
For twelve years we have explained the same things in meetings, proposals, and code reviews: when it makes sense to split a system into services, what to check before migrating an Adobe Experience Manager project, why a slow site is rarely fixed by a bigger server. Those explanations stayed in an email or a call. The blog is where they finally get written down, dated and signed.
It is also a consequence of our 2026 refocus. Editando Ideas stopped presenting itself as an agency and became an engineering and technology talent consultancy. A service catalog says what we do; an engineering blog shows how we think. The second is what a team needs to know before trusting us with its system.
What we will write about
Only what we do every day. There are seven tracks, and the first posts focus on the top three, which is where we get the most questions.
- Adobe Experience Manager: AEM as a Cloud Service, Cloud Manager, Dispatcher, Content Fragments, and migrations from AEM 6.5.
- Architecture and development: APIs, microservices, legacy modernization, and when custom software actually makes sense.
- Technical audits: how we review code, dependencies, security, and performance, and how we prioritize what we find.
- Cloud and operations: environments, continuous integration and delivery, secrets, backups, and observability on Google Cloud and Firebase.
- Talent and nearshoring: how to bring an external engineer or a dedicated cell into your team without losing technical control.
- Product and websites: information architecture, accessibility, Core Web Vitals, and redesigns that keep what is already indexed.
- Technical SEO and AI search: sitemaps, canonicals, hreflang, structured data, and how to prepare a site for generative search engines.
How we write
Every post follows the same rules we apply to this site:
- Answer first. If the title asks a question, the first paragraph answers it; context and nuance come after.
- Our own experience before definitions. We would rather explain what we check before migrating an AEM project than explain what AEM is. When an example comes from a client, we anonymize it unless we have permission to name them.
- No unsupported numbers. If something has not been measured, we say so. We do not publish invented metrics or promise outcomes.
- Sources and dates. We cite official documentation when it exists, and every post shows when it was published and last updated.
- A named author. Every piece is signed by the person who wrote it and who stands behind it.
- In both languages. We publish in Spanish and English, and each version is reviewed for the people who will read it.
What you will not find
We would rather publish one useful article than four nobody finishes. So there will be no:
- Company news or announcements dressed up as articles.
- Generic listicles that could live on any other site.
- Mass-produced posts written to fill a calendar. We use AI tools to review and translate, but the technical opinions, the examples, and the mistakes we describe are our own.
What comes next
Every article links to the service it relates to and, when there is one, to the case study behind it. If something you read looks like your situation, you can follow the thread all the way to a conversation with us.
If you would like us to write about a specific topic, tell us. The best posts usually start with a question from someone about to make a decision. And if you would rather hear about new posts without coming back to check, the blog has an RSS feed in English and another in Spanish.