Ascendra Ventures · IT services, re-founded

One atomic technology problem. Autonomously solved.

We are founders who build, generative AI systems, DevOps pipelines, and SaaS products for web and mobile. While the industry bills hours against endless scope, we isolate the one technology problem that matters and hand you the working answer, at a fixed price, in weeks.

The industry sells time. We sell the answer.

Most service firms keep the meter running. Scope grows and the problem quietly outlives the engagement. Ascendra is structured the other way: one technology problem, one build, one verdict, a fixed price per problem, never a running meter.

1. Isolate. We sit with the noise and find one technology problem whose answer changes the business. Week zero · You hold: a one-page problem map
2. Strip. Everything else is set aside. What remains is a single atomic requirement, stated in one sentence. Weeks 1–2 · You hold: the atomic problem statement and a fixed price
3. Build. Our own team builds it autonomously, outside your process. No steering committees, no timesheets. Weeks 2–7 · You hold: working software, dropped weekly
4. Prove. You receive the working solution and the evidence around it. Final week · You hold: the evidence pack
5. Own. Code, infrastructure and documentation transfer to you. Your team runs it without us. After hand-over · You hold: everything

What we build

• AI development, Generative AI and machine learning: LLM applications, RAG systems, AI agents and risk models, taken from notebook to production with the numbers to prove it. Stack: Python, PyTorch, LangChain, RAG, OpenAI, Anthropic Claude, Hugging Face, FastAPI, Pinecone, PostgreSQL.
• DevOps, DevOps and platform engineering: Kubernetes, Terraform and CI/CD pipelines on AWS and Google Cloud that turn releases from events into routine. Stack: Kubernetes, Docker, Terraform, GitHub Actions, CI/CD, Prometheus, Grafana, AWS, Google Cloud, Redis.
• Application development, Full-stack SaaS and product development: web and mobile frontends in React, React Native and Flutter, with the backend APIs, services and data layer built alongside, proving a business case in weeks. Stack: React, Next.js, TypeScript, React Native, Flutter, Swift, Kotlin, Node.js, FastAPI, PostgreSQL, Supabase, Redis.

Who we serve

• For large corporates, one technology problem out of committee
• For startups, the MVP worth building

Case files

• The candidate pipeline that could not get stuck, Candidate enrichment was not an API problem. It was a workflow reliability problem.
• Identity-anchored AI link discovery with Exa, You do not need to crawl the whole web. You need an AI pipeline that finds one person's real links with Exa and rejects same-name impostors.
• AML and CTF compliance software for Tranche 2, Small firms do not need a compliance consultancy. They need guided AUSTRAC Tranche 2 workflows they can run themselves, in a browser.
• The egg supply chain on one real-time dashboard, The egg business did not need an ERP. It needed one live dashboard where sales, stock, demand, and logistics finally sat side by side.
• The skills engine that became EY Spotmentor, Enterprise skilling was not a content problem. It was a matching problem: which skill, for which person, against the jobs the market is creating next.
• A WordPress site rebuilt to deploy itself on Cloud Run, A website is not a server you log into and edit in place. It is an image you build once and promote, with content authored once instead of twice.
• A research assistant that reads the literature overnight, Assessing an early-stage poverty intervention was not a reading problem. It was a retrieval and mapping problem: find the evidence, arrange it into an impact pathway, and keep the researcher in charge.
• Warranty documents that read themselves, Missed warranty deadlines were not a diligence problem. They were an extraction problem: the terms were buried in PDFs nobody had time to read.
• One AI desk over a ministry's scattered knowledge, The ministry's answers already existed. They were spread across portals, PDFs, and transcripts that nobody could query in one place.
• Fifteen months to retire the legacy pipeline, Slow, error-prone releases were not a people problem. They were a pipeline problem: legacy CI, inconsistent workflows, and deployments done by hand.
• A private cloud carved out of the server room, The server room was not out of capacity. It was out of shape: one VM per app, no shared observability, and nothing self-service.
• From hand-built servers to containers in production, The product was not fragile. Its runway was: four services on hand-managed servers, with no repeatable path from a developer's change to production.
• Three payment products behind one front door, Three payment products were not three businesses. They were one platform waiting for a single front door.
• From brochure site to a store that serves dealers too, Retail buyers and dealers did not need two systems. They needed one storefront that knows who is looking at it.
• The front door of a national member portal, rebuilt, The portal did not need a replatform. It needed a new front door: registration, login, and roles rebuilt over the CMS and CRM already running the organization.
• Three internal systems in nine months, without a dev team, Internal tools did not deserve a product team's budget. They needed a platform where a small team ships one app a quarter.
• A GenAI platform for an airport, answered with working bots, An airport does not need a chatbot. It needs a platform: voice, video, and text assistants on one architecture that survives peak traffic and audits alike.
• IT support that lives where the users already are, Support adoption was not a training problem. It was a location problem: the users lived in Microsoft Teams and the agents lived in the contact center, with nothing in between.

Journal

• I built a second brain for my AI agents. The hard part wasn't the AI., I spent a month teaching my AI tools to remember who I am and how my world works. The interesting part turned out to be the boundary: where to let the model decide, and where to never let it.
• The billable hour is a conflict of interest, When a firm is paid for time, the problem becomes an asset. On why we price the answer, never the meter.
• Finding the atomic problem inside a transformation programme, Every forty-slide programme hides one sentence worth solving. A field guide to extracting it before the committee does.
• The first technology decision most founders get wrong, It isn't the stack. It's building the platform before the question, and paying compound interest on certainty you don't have.

Built, shipped, and in the works

• Actofit Scale Dashboard, A rebuilt home for your body-composition scale
• Resume Labs, the only place which lets you land a job which you want
• PocketPulse, launch your portfolio website with a click of a button

Three questions

What does “one atomic technology problem” actually mean?

It is the smallest technology problem whose solution changes a business number someone cares about. Most briefs arrive as five or six asks tangled together. We spend the first conversation stripping them back until one requirement remains that is small enough to build quickly and big enough to matter. That is what we take on.

What does it cost?

A fixed price per problem, agreed before we start. We do not bill hours, because the billable hour rewards the wrong behaviour. If the scope was wrong, that is our miss to absorb, and we treat re-scoping as our cost of learning.

How long does a build take?

Weeks, as a rule. An atomic technology problem that needs a quarter is usually two problems wearing a coat. Typical engagements run three to eight weeks from discovery call to hand-over.

All questions, answered