Build it with AI? Why the AWS SDK for Delphi still wins

You can ask an AI to write AWS code for Delphi, and it will produce something that works. That's not in dispute, and this page won't pretend otherwise. The question worth asking is narrower: for what you're trying to do, is generating it yourself the cheaper option once you count everything, or only the cheaper-looking one?

If you genuinely need one thing, generate it

If you need a single PutObject, one Parameter Store read, or a script you'll run a few times and throw away (and it runs on your own machine, where your credentials already live in your environment), you don't need this SDK. Ask the AI, take the dozen lines it gives you, and move on. We'd rather tell you that than sell you something you don't need.

That carve-out is narrower than it sounds. "Runs on your own machine, where your credentials already live" describes almost no software that ends up mattering to anyone other than you. The moment you ship it, deploy it, or hand it to someone else, you've stepped outside it, which is the next point.

"One call" is rarely one call

The moment that same operation has to run on AWS rather than your laptop, it stops being one call. A PutObject on ECS is not "upload a file": it's resolve credentials from the container's task role, often assume a role through STS to get the permissions you actually need, and then make the S3 request. That's three things across two services before you've uploaded a single byte, and the credential-resolution part is exactly the part a generated snippet gets wrong.

Ask for narrow AWS code and you'll almost certainly get static credentials written straight into the source, because that's the simplest thing that satisfies the request, and the model has no idea where the code will end up running when it answers. It runs on your machine. Then you deploy it to ECS or EC2 and it's wrong. Not because it fails to compile, but because hard-coded keys are exactly what you're not supposed to ship, and because that code has no way to pick up an ECS task role or an EC2 instance profile, no way to assume a role through STS, no way to handle temporary credentials that expire and need refreshing. To go from working-locally to running-on-AWS you end up changing production code, which is precisely the seam where mistakes get made.

This is why the official AWS SDKs carry a credential provider chain and config loading that looks more complicated than it seems it should be. It's what lets the same code resolve credentials from the environment, a profile, a task role, an instance profile, or an assumed role without you rewriting anything between dev and deployment, and refresh them when they expire. We mirror that behaviour deliberately, and we've built and tested it, because it's the difference between code that demonstrates an API call and code you can actually deploy.

We go further in the same spirit: HTTP networking handled consistently across services, with automatic retries on the failures AWS expects you to retry, using jittered exponential backoff so a transient error or a throttle doesn't take your application down. None of this is in scope for "upload this file to S3." All of it is part of working with AWS robustly rather than just successfully once.

What the narrow script leaves out

A one-off script is cheap because it skips the parts that take the time. Those parts arrive later, usually in production:

The AWS documentation and the AWS reality are not always the same thing. Anyone who has shipped against AWS for long enough has met behaviour the published reference doesn't quite describe: response details that vary by service, error shapes that don't match the examples, signing cases the docs gloss over. We've met them too, over years of shipping this SDK, and dealt with them so they don't land on you. Generated code follows the documentation, which is where those gaps live.

Then there is everything that isn't a single request: paginated results and the helpers that turn a raw API into something pleasant to call. Each is straightforward in isolation and tedious in aggregate, and each is a thing you now own and maintain.

And AWS does not hold still. Every new field or operation is another pass through the same generate-and-debug cycle, months later, with the context long gone from your head. AWS migrated SQS from XML to JSON in 2024; our 2.0 release absorbed the change so customers didn't have to. Generated code doesn't get that.

What you get

Beyond credentials and retries, the £149 covers the surface area Delphi developers reach for: S3, SQS, SNS, SES, IAM, KMS, Secrets Manager, Cognito, IAM Identity Center, Polly, Textract, Rekognition, Translate, Transcribe, STS, and growing. Alongside the raw service clients there are higher-level conveniences: SQS queue pollers, S3 pre-signed URL helpers, file and stream uploaders, waiters, SNS message verifiers, an IAM policy document builder. Each of those is something you would otherwise build, less well, around generated calls.

The licence is perpetual, and it comes with 12 months of updates and support. Every new service and every fix we ship inside that window is included.

AI plus the SDK

The case in this piece isn't AI versus the SDK; it's that AI with the SDK in the loop beats AI on its own.

Every language model has finite context. The more of it you spend reminding the model how credentials resolve, what to retry, which protocol SQS speaks this year, the less you have left for the thing you're building. The SDK takes those concerns out of the prompt: the model doesn't need to hold them because the SDK already does. Ask for an S3 upload, get an IS3Object.UploadFile call, and credentials, retries, multi-part chunking, and signing are handled before the request leaves the wire.

Our reference documentation is at docs.appercept.com; AI agents can read it the same way they read any other reference. From the model's perspective, the SDK is a smaller, more stable surface than AWS itself: less to hold in the prompt, less to get wrong.

Tested, in the field, by people who'd tell us

This SDK is built test-first, and it's in production across our customer base: Delphi applications running on Windows, macOS, iOS, Android, and Linux, on x64 and ARM, in places we couldn't anticipate. That second part matters more than the first: real users on real platforms are the test suite you can't write, the one that finds what your own assumptions missed. If something breaks, we hear about it and we fix it. Code you generate for yourself has neither: no accumulated suite, and no one but you to notice when an edge case fails. You start that coverage from zero, and you build it the expensive way, one production incident at a time.

The cost you don't see on an invoice

Generating the code looks free because the meter you can see — the token spend — is the small one. The real cost is the time around it: prompting for something deployable rather than something that merely runs, reading and reviewing what comes back, finding the case it got wrong, and going round again. For anything past a trivial call that work is measured in hours, and a senior Delphi developer's hours are the most expensive line in any project. Then the same hours are spent again the next time AWS changes or you reach for another service.

Set that against £149 (on the order of a couple of hours of that same developer's time), paid once, for code that already does the deployable version rather than the runs-on-my-machine version. The arithmetic isn't close the moment your AWS use is real and ongoing rather than a one-off you'll never touch again.

Who carries the cost

The difference that matters in the long run is not the first build. It's who pays for the work, and how often.

When we build and maintain this SDK, the design, the fixes, the tests, and the upkeep as AWS changes are paid for once and spread across everyone who buys a licence. Your £149 buys a share of work already done, and a maintenance burden you hand to us.

Build the equivalent yourself and there is no one to share it with. You pay for it in full, on your own, and you pay again each time AWS moves or you need another service. That is the structural reason a maintained SDK tends to win for anything beyond a throwaway: it divides a cost that doing it yourself leaves entirely on you.

The short version

For one call that runs where your credentials already are, generate it yourself — genuinely, don't buy anything. For anything that deploys to AWS, talks to more than one service, or needs to survive AWS changing underneath it, the Standard Edition is £149: roughly two to three hours of a developer's time, paid once for a perpetual licence, for code that's tested, maintained, and already past the problems you'd otherwise meet one at a time. 12 months of updates and support are included.

If you're weighing this up at all, you're almost certainly past the threshold where the second option wins.