stop waiting for permission to solve your own problems. the platform provides the foundation, but you’re still the one responsible for the structural integrity of the solution.
there is a specific kind of friction that happens in software when a requirement moves faster than a product’s development cycle. it’s not that the toolset is broken; its “out of the box” capabilities just haven’t caught up to your enterprise reality yet.
recently, we hit one of those “not yet” moments with outsystems developer cloud (odc).
the environment is evolving quickly, and while it offers a native gemini integration, that feature is currently built for the simplicity of public api keys. for a project that requires the “industrial strength” of vertex ai gemini, running inside a google cloud (gcp) perimeter with full iam governance, the functionality we needed is simply buried deep in a future backlog.
instead of standing by for a vendor update to arrive, we decided to see how much we could accomplish with a little autonomy in our design.
the roadmap trap
in many organizations, “not supported” is the end of the conversation. you file a feature request, hope it gets move up the list, and let your project stall.
but waiting for permission to construct a secure approach is a risk in itself. as software becomes more front-loaded, the responsibility shifts back to the engineer to decide which constraints are hard boundaries and which ones are just suggestions.
we chose to earn the extra effort of a bespoke path because the alternative, compromising on our data protection standards, was a long-term liability we weren’t willing to own.
building bridges
we realized that odc doesn’t actually care who it’s talking to; it just cares that the conversation follows a specific restful contract. if we could develop a mediation layer that “pretended” to be a standard endpoint while handling the heavy lifting of the google authentication handshake on the back end, we could own the outcome.
the process was less about writing a finished product and more about finding the exact point where the connection would snap:
the build: we used fastapi and pydantic to develop a translation service that maps odc’s payloads to vertex ai’s sdk requirements.
the break: we discovered that passing multi-modal data (like pdfs or images) requires a very specific encoding for data urls. if the decoding isn’t pixel-perfect, the whole thing just goes dark.
the learn: the hardest part wasn’t writing the python code. it was the mapping, realizing that “supported” is a relative term. if you can speak the protocol, you can bypass the delay.
why this earns its complexity
every piece of custom implementation in a low-code environment adds weight. it’s an extra asset to maintain and a new set of trade-offs to accept.
but this design earned its right to exist. by choosing to build it, we didn’t just solve a technical mismatch; we preserved the safeguards the project demanded. we traded the convenience of a native connector for the absolute clarity of a governed system.
the distance between “not yet” and “working in production” is usually just a matter of how much you’re willing to build for yourself.
when the platform hits its ceiling, the real work of the architect actually begins.
if you want to see the literal “how” behind this experiment, including the python code and the odc configuration, I’ve done a full technical deep dive over at af tech blog. you can find the blueprints and the detailed lessons from the “break” cycle there.
