About
Twenty-three years of technology decisions, applied to the ones that are expensive to reverse
I design and build secure digital platforms and AI-enabled business applications for founders, regulated organisations and leadership teams. The career ran from enterprise infrastructure through technology leadership and cybersecurity governance into product development — each stage making the next one more defensible.
- Experience
- 23+ years in technology leadership
- Sectors
- BFSI, healthcare, education and professional services
- Focus
- Technology strategy, AI products, security and compliance
- Based
- Mumbai, India — working with clients in the UK, US and EMEA
Profile
Jordan Dias
Technology Strategist & Product Builder
- Mumbai, India
- diasjordan@gmail.com
I design and build secure digital platforms and AI-enabled business applications for founders, regulated organisations and leadership teams — from first scope through to a version real customers use.
23+ years in technology leadership across BFSI, healthcare, education and professional services, moving from enterprise infrastructure through technology leadership and cybersecurity governance into product development. Each stage still shows up in the work: architecture decisions are made with cost and risk stated plainly, and access control, evidence and auditability are designed in rather than added later.
Engagements range from fixed-scope discovery through full platform delivery to retained fractional technology leadership. Based in Mumbai, India — working with clients in the UK, US and EMEA.
The short version
Four questions, answered directly
Everything else on this page is detail behind these four answers.
Who is Jordan Dias?
A technology leader with more than 23 years spent inside regulated businesses — first building and running enterprise infrastructure, then leading technology functions, then owning cybersecurity and governance, and now designing and building AI-enabled products. Not a freelance developer taking briefs, and not a consultancy selling capacity. The work is senior judgement applied to decisions that are expensive to reverse.
Why build software at all?
Because in most businesses the constraint is not effort, it is coordination. Work waits on a person to move it, records live in inboxes and spreadsheets, and nobody can answer a simple question about the state of things without asking three people. Software is worth building when it removes that coordination cost permanently. When it will not, I say so.
What makes the approach different?
Most build engagements start with a feature list. Mine start with the decision the business is trying to make and the evidence it needs to make it. Discovery is short and produces a costed plan, a prototype and a defensible architecture. Security, access control and audit trails are specified at design time, because they cannot be added to history that was never recorded.
Why should a business trust this?
Because the same person who writes the architecture has sat on the other side of enterprise security reviews, procurement questionnaires and audits, and has been accountable for the answers. Scope, trade-offs and the things I would not build yet are stated in writing before work begins, and delivery happens in increments you can review rather than a single reveal at the end.
Professional journey
Infrastructure, then leadership, then governance, then products
Not a pivot. Each stage answered a question the previous one raised, and every stage still shows up in the work.
- 01Early career
Enterprise infrastructure
Datacentre, network, systems and continuity work inside banking and financial services, where downtime is measured in money and every change has a paper trail. This is where the habit of designing for failure rather than for the demo was formed.
Carried forward: Operational realism: systems are judged on the bad day, not the launch day.
- 02Mid career
Technology leadership
Accountability shifted from systems to outcomes — budgets, vendors, delivery standards and the sequencing of technology work against commercial milestones. Sitting in the room where spend is approved changes how you scope work.
Carried forward: Commercial framing: every technical decision stated as a business consequence.
- 03Regulated years
Cybersecurity and governance
Ownership of security posture, access control, supplier assurance, policy and the evidence that satisfies auditors and enterprise buyers. Governance stops being paperwork once you are the one signing the response.
Carried forward: Evidence by design: controls and audit trails specified before the first line of code.
- 04Now
AI-enabled product development
Designing and building platforms and products where language models do specific, testable work inside a reviewed workflow. The infrastructure, leadership and governance experience is what makes this responsible rather than speculative.
Carried forward: Applied AI: used where it improves an outcome, declined where it cannot be verified.
Personal philosophy
How I think
These positions decide scope and architecture long before they decide code, and they are the reason some proposals get smaller after the first conversation.
Technology exists to solve business problems
If a decision cannot be traced to a commercial outcome in one sentence, it is usually premature. Architecture diagrams are not the deliverable; a business that works differently is.
Building less software is usually better
Every feature is a permanent liability — it has to be supported, secured, explained and eventually replaced. The strongest contribution I make on most engagements is removing things from the plan.
Architecture decisions outlive technology choices
Frameworks and vendors get replaced without much pain. Data models, boundaries between systems and the way permissions are expressed do not. Those get the disproportionate share of the thinking.
Security and governance belong in the design
Access control, data separation and audit trails cannot be backfilled, because history that was never recorded cannot be recovered. Designing them in costs days; retrofitting them costs quarters.
AI should improve outcomes, not automate inefficiency
Applying a model to a broken process makes the process faster and no better. The useful question is which judgement is expensive, repeatable and verifiable — and only then whether a model can do part of it.
Adoption is the only honest measure
A platform nobody uses is a failed platform regardless of its test coverage. Onboarding, migration and handover are part of the work, not a phase that follows it.
My approach
How the work actually runs
In the order it happens on a real engagement, from framing the constraint to handing over something another team can maintain.
- 01
Business-first framing
The engagement opens on the constraint and the commercial decision behind it, not on a feature list or a technology preference.
- 02
Strong discovery before development
A short, fixed-scope discovery produces a validated scope, a costed delivery plan and a defensible architecture — separable enough to be taken elsewhere.
- 03
Rapid prototyping
Something clickable early, while changing direction is still cheap. Opinions about a screen are more reliable than opinions about a specification.
- 04
Practical architecture
Boring, well-understood components chosen for the load that actually exists, with the seams placed where growth is most likely to arrive.
- 05
Iterative delivery
Reviewable increments on a predictable cadence, so scope can be corrected while it is still inexpensive to correct.
- 06
Built for maintainability
Written so another team can take it over: documented decisions, conventional patterns, no cleverness that needs its author present.
- 07
Clear stakeholder communication
Progress, risk and cost explained in the language of the business, in writing, without needing an engineer to interpret it.
What clients can expect
Six things that hold on every engagement
Stated here so they can be held against the work rather than discovered at the end of it.
Strategic thinking
Work sequenced against commercial milestones, with cost, risk and dependency stated plainly rather than discovered later.
Honest recommendations
Including when the answer is a smaller build, an existing product, or not yet. Saying so early is more useful than agreeing and finding out afterwards.
Executive communication
Board-ready summaries and direct written updates. Nothing important is left to be inferred from a ticket board.
Security-conscious architecture
Access control, data separation and audit evidence specified at design time, and defensible in front of a security review.
Product ownership mindset
Accountability for whether the thing works in the business, not only for whether it was delivered to specification.
Fast execution
AI-assisted delivery compresses build time substantially. Judgement, review and security standards stay human.
Experience timeline
Capability, not employers
Which capabilities were built when, and where each one still applies. Nothing here has been retired — later work is layered on top of earlier work.
- 2003 onwards
Enterprise infrastructure
Networks, systems, datacentre operations, resilience and continuity in BFSI environments with real availability obligations.
- 2009 onwards
Technology leadership
Owning budgets, vendors, delivery standards and technology roadmaps, and defending them to non-technical decision makers.
- 2013 onwards
Cybersecurity
Security architecture, identity and access, threat and vulnerability management, incident response and enterprise security review.
- 2016 onwards
Governance and compliance
Policy, control frameworks, supplier assurance, data protection obligations and the evidence auditors and enterprise buyers require.
- 2019 onwards
Product strategy
Discovery, scoping and validation: deciding what to build, what to defer and what to decline before budget is committed.
- 2021 onwards
Startup and founder experience
Building products under real constraint — small teams, finite runway, decisions made with incomplete information and owned anyway.
- 2023 onwards
AI products
Designing, evaluating and shipping AI-enabled features with tested prompts, measured outputs and human review where the result matters.
Working principles
Working principles
Short enough to be held to. These are the tests a proposal has to pass before I put my name on it.
- Solve the right problem before building
- Most failed platforms were built competently against the wrong problem statement.
- Business outcomes over technical complexity
- Sophistication that no commercial outcome depends on is cost without return.
- Keep products simple
- Fewer concepts, fewer screens, fewer states. Simplicity is what makes software teachable.
- Build for maintainability
- Assume the team that inherits this does not have access to whoever wrote it.
- Design for scale, build for now
- Leave the seams where growth will arrive; do not pay for that growth before it does.
- Measure success through adoption
- Usage by the people whose work it was meant to change is the only result that counts.
Areas of expertise
Where the experience is concentrated
These reinforce one another. A platform built without governance fails security review; governance without delivery capability produces documents nobody uses.
- AI product development
- Selecting, evaluating and shipping AI-enabled features that are tested against real data and reviewed by a person where the output matters.
- Technology strategy
- Sequencing technology work against commercial milestones, with cost, risk and dependencies stated plainly.
- Custom business platforms
- Replacing manual processes, spreadsheets and disconnected tools with systems the team adopts because they remove work.
- Cybersecurity governance
- Access control, evidence, supplier assurance and the documentation enterprise buyers and auditors ask for.
- Privacy and compliance
- Turning data protection obligations into tracked work with owners, evidence and deadlines held in one system.
- Technology leadership for regulated businesses
- Senior accountability for delivery and security standards in organisations where evidence and auditability are non-negotiable.
- Product discovery and MVP development
- Turning an idea or mandate into a validated scope, a costed plan and a first version real customers can use.
Questions
Frequently asked
The questions asked most often before an engagement begins, answered without qualification.
What types of businesses do you work with?
Founder-led startups, growing mid-sized businesses, regulated organisations in healthcare, financial services and education, private equity portfolio companies, and professional services firms productising their expertise. The common factor is a decision that is expensive to get wrong, not a company size.
Do you build products from scratch?
Yes. Discovery, architecture, design, build and launch of new platforms and products, including AI-enabled ones. Engagements usually start with a fixed-scope discovery that produces a validated scope, a prototype and a costed delivery plan before any build commitment is made.
Can you work with existing engineering teams?
Yes. That is a common arrangement: I provide architecture, delivery standards, security posture and technical review while the in-house or outsourced team builds. The intent is to raise the team's ceiling, not to replace it.
Do you provide technology strategy?
Yes, as fractional technology leadership — typically one to four days a month covering architecture, roadmap sequencing, vendor and build-versus-buy decisions, security posture and board-level reporting.
Can you help validate product ideas?
Yes. Product discovery is a distinct, fixed-scope engagement ending in a validated scope, a working prototype and a costed plan. It is deliberately separable, so the plan can be delivered by another team if that is the better commercial choice.
Do you build AI products?
Yes, where the model does specific, testable work inside a reviewed workflow — extraction, classification, drafting, summarisation and assisted review. Where output cannot be verified against real data, I recommend against using a model rather than shipping something unaccountable.
Do you work internationally?
Yes. Engagements are delivered remotely for clients in India, the United Kingdom, the United States and EMEA, with working hours agreed to give a reliable overlap.
How do engagements typically begin?
A short written summary of the business context and the constraint, then a 30-minute call. If it is a fit, the first commitment is a fixed-scope discovery rather than an open-ended build.
Current focus
Current thinking, decisions and delivery detail are published as Insights and case studies.
Let's discuss your next product, platform or technology initiative.
Send the business context and the constraint you are working against. I will reply personally with a direct read on the approach I would take, and whether I am the right person for it.