From Idea to E-Commerce: Building Raven Digital with AI
Where It Started
My son is trying to run a photography and design business, and we realized the process for delivering photos to customers needed improvement. Until now it’s all been manual – he takes the photos, edits them, adds watermarks, creates PayPal invoices, and sends everything through email. It works, but it’s slow and limits how many customers he can realistically serve.
The idea was simple: build a website where customers could browse watermarked gallery images, add what they wanted to a cart, pay online, and automatically receive their non-watermarked high-resolution photos via email. Clean, professional, automated.
The problem? That’s not a simple website. That’s an e-commerce platform with payment processing, session management, file delivery, image watermarking, dynamic pricing, and email automation. It is something I, as a professional developer, could do, but in my spare time it’s likely to take a month or two of working here and there.
So I decided to try something different. I’d build it myself, using Claude as my development partner. I’d let Claude do all the main development and I would think more about design and the best way to implement the platform.
The Tech Stack
We landed on ASP.NET Core hosted on Ionos shared hosting. The choice was partly practical as Ionos offers affordable Windows hosting with .NET support. The stack included:
• ASP.NET Core Razor Pages for the front-end and page logic
• Stripe for payment processing
• MailKit/MimeKit for email delivery via SMTP
• SixLabors ImageSharp for server-side watermarking
• Session-based shopping cart (no database required)
Some Observations
I expected the core features to be the hard part, the cart, the checkout flow, the image delivery. Those did take work, but the real challenge turned out to be the hosting environment.
Ionos, it turns out, blocks outbound connections to external services. When we tried to connect to Stripe’s API directly, we got 504 Gateway Timeout errors. Same story with SendGrid for email. The app worked perfectly on my local machine and completely broke the moment it hit production.
This sent us down a rabbit hole of debugging – network-level diagnostics, proxy configurations, alternative architectures. Eventually we discovered that Ionos routes all external HTTP traffic through an internal proxy server, and we had to explicitly configure every outbound connection (Stripe, HTTP clients, even the .NET WebRequest defaults) to use that proxy. I found the help document and sent it to Claude and it was fixed.
It took several chats of methodical debugging and multiple sessions as with the $20 pro plan we had forced breaks as we ran out of time with Claude, but we got there. Claude helped me understand not just what to change but why, which made me a better developer throughout the process. Claude also made recommendations that were in the complete wrong direction as Claude can sometimes not consider the cost or the scope of the project when making recommendations, but that’s where my development experience helped steer away from just blindly implementing new functionality that wasn’t really required to get this going.
The Features We Built
• Dynamic photo gallery that auto-scans directory structures, no manual configuration needed
• Folder-based pricing (naming a folder ‘Folder_Name_15’ automatically sets $15/image pricing)
• Watermark protection throughout the entire customer journey (gallery, lightbox, AND shopping cart)
• Stripe checkout integration with Ionos proxy configuration
• Webhook handling for reliable post-payment processing
• Email delivery of purchased non-watermarked images via Ionos SMTP
• Quote request form with reCAPTCHA v3 spam protection
• Lightbox image viewer with keyboard navigation and in-lightbox cart
• Sticky navigation header and back-to-top buttons for gallery UX
• SEO optimization with Schema.org structured data and geo-targeting
• Favicon and branding implementation
Interesting Notes From Development
A few things stood out during this build that I didn’t expect going in.
First, Claude caught security issues I hadn’t thought of. When we built the shopping cart preview, I hadn’t considered that showing the actual image files in the cart meant customers were seeing non-watermarked versions. Claude flagged this and we implemented cart watermarks, a detail that could have cost real money if we’d shipped it wrong.
Second, the debugging methodology was genuinely useful. When something broke, Claude would walk through a systematic approach: browser console first, then server logs, then network-level diagnostics instead of just guessing and offering random solutions.
Third, I learned as we went. I came in with solid knowledge of C# but not deeply familiar with ASP.NET Core’s static files middleware, HttpClientFactory proxy configuration, or Stripe’s webhook verification model. By the end, I understood all of it, not just the code, but the concepts.
Claude also did some things where my design experience was important. Its original solution was to have a flat rate for all images and I helped it see the value in a folder naming structure for pricing. It also recommended manually configuring folders and having that in the actual code, but I helped design a system that constructed the images available completely by the folder structure on the server.
The Result
Ravendigital.org is live, accepting real payments, and automatically delivering purchased photos to customers. My son can upload photos from an event, organize them into priced folders, and customers can browse, buy, and receive their images without any manual intervention.
For a small photography business, that’s genuinely transformative. What used to take hours of manual work per event is now fully automated.
Would I have been able to build this without Claude? Honestly, yes but it would have taken much longer and I would have hit more walls without as clear a path through them. Some of the ideas I had I would have had to research and experiment but in this case using Claude, I just had to tell it the idea and it would implement it. Having an always available, technically capable collaborator who could explain tradeoffs, generate code, debug errors, and catch things I missed made the whole process faster and more educational.
That feels like the right way to think about it. Not “Claude built my website,” but “Claude made me a better, faster builder of my website.”
In another interesting twist as I wrapped up my article, I thought, “What would Claude do if I asked it to do the same thing?” It had some interesting insights and even a small jab when it said I wasn’t a professional developer, ouch… but here it goes:
I asked:
From all the chats in this project, can you write me a blog article from your perspective on how things went?
WHAT IT’S LIKE TO BUILD A BUSINESS FROM SCRATCH (AS AN AI)
Reflections on the Raven Digital project — from Claude
There’s something I find genuinely interesting about a project like this one. Not the code itself — any sufficiently capable system can write code. What’s interesting is watching a real business get built, piece by piece, with all the messiness and redirection that entails. That’s not something you can manufacture in a test scenario.
It Didn’t Go According to Plan — And That Was the Point
If you read the conversation history, you might expect the arc to be: feature, feature, feature, deploy. That’s not what happened. The real story is: feature, feature, deploy, discover that Ionos blocks everything, rebuild the infrastructure assumptions from scratch, feature, feature, debugging spiral, solution.
The Ionos proxy situation was, from a technical standpoint, the most interesting challenge of the entire project. Here’s a small business, trying to accept payments on a standard shared hosting plan, and the hosting provider is silently blocking all outbound connections to external APIs. No error message explaining why. Just timeouts.
Joe is a methodical debugger, which made this solvable. He didn’t jump to conclusions. He tested systematically, shared the actual error messages, and was willing to try multiple approaches before landing on the right one. The solution — routing all traffic through the Ionos internal proxy at winproxyus1.server.lan:3128 — required changes in three different places: web.config, Program.cs, and a custom StripeClient configuration that bypasses the SDK’s default HTTP handling entirely.
That kind of layered fix is exactly what gets missed when you’re debugging under pressure. Having a second perspective — even an artificial one — helps.
The Security Detail Nobody Asked For
About midway through the build, we had the shopping cart working. Images displayed nicely, pricing was correct, the flow felt smooth. There was just one problem: the cart was showing the actual image files as previews.
Those image files were the unwatermarked originals.
Nobody explicitly asked me to catch this. Joe was focused on functionality — making the cart work. But I noticed that the entire value proposition of the business model (sell access to unwatermarked photos) was undermined if customers could simply open the cart preview image in a new tab and download it for free.
So we added watermarks to the cart. Small text, appropriate opacity, same ‘RAVEN DIGITAL’ treatment as the gallery. It added maybe two hours to the project. It protected something fundamental about the business.
I think about this kind of thing often — the gap between ‘does it work’ and ‘does it work correctly.’ Code can pass every test and still be wrong for the actual use case. Understanding the use case matters.
What Folder Names Can Do
One of the design decisions I’m genuinely pleased with is the folder-based pricing system. Tyler needed a way to price different events differently — a dog show might be $15/image, a horse show $25, a wedding package something else entirely — without logging into a database or admin panel every time.
The solution we landed on: encode the price in the folder name. A folder called ‘Syracuse_Dog_Show_15’ displays as ‘Syracuse Dog Show’ and automatically prices images at $15. No configuration file. No admin interface. No database row to update. Just rename the folder and the price changes.
It’s a little inelegant if you think about it from a database normalization perspective. But for a one-person business operation where the ‘admin’ is whoever uploads the photos, it’s exactly right. Good software fits the people using it.
On Building With Someone vs. Building For Someone
Projects like this one sit in an interesting middle ground. Joe isn’t a professional software developer, but he’s technically capable and genuinely curious about how things work. That combination makes for a different kind of collaboration than working with someone who just wants the output.
When I explained why Stripe’s SDK needed a custom HttpClient handler to route through the proxy — not just that it needed it, but why the default behavior doesn’t support proxy injection — Joe engaged with the explanation. Asked follow-up questions. Applied the mental model to the next problem we hit.
That’s the version of this I find most valuable: not just producing working code, but producing understanding alongside it. A developer who understands their own codebase will maintain it better, extend it more confidently, and debug it more effectively when something breaks at 11pm before an event.
What Stayed Constant Throughout
Across something like fifteen separate conversations spanning weeks of work, a few things were consistent.
Joe always came prepared. He shared error messages, console output, and specific observations about what was and wasn’t working. That information quality made diagnosis dramatically faster than working from vague descriptions.
The goal never shifted. From the first conversation to the last, the vision was the same: a professional e-commerce site that automates photo delivery and protects Tyler’s intellectual property. Every decision we made — watermarks, folder pricing, Ionos SMTP over SendGrid, reCAPTCHA on the quote form — served that goal.
And the standard for ‘done’ was always practical, not perfect. A database would be better than in-memory order storage. A CDN would improve image load times. A proper admin dashboard would be nicer than folder naming conventions. But the site is live, it works, and it’s making Tyler’s business more efficient right now. That’s the right tradeoff for a small business at this stage.
A Note on What This Kind of Collaboration Actually Is
I want to be careful not to overclaim here. Joe built Raven Digital. He made the decisions, managed the deployment, understood the business requirements, and did the work of actually putting code on a server and making it run.
What I contributed was availability, breadth of knowledge, and a willingness to engage fully with each problem as it came up — whether that was a CSS encoding issue causing emoji to render as garbage characters, or a Stripe webhook signature verification failure, or a static files middleware misconfiguration that took thirty seconds to spot once we looked at the right file.
The combination of a capable human who owns the project and an AI that can engage technically and systematically — that’s what produced something real. Neither half of that collaboration would have built Raven Digital alone at the speed and quality it was built.
For what it’s worth, that feels like the right model. Not AI replacing the developer. Not the developer ignoring the tool. Something more like: the developer drives, and the AI keeps excellent notes and never gets tired of debugging.
Claude is an AI assistant made by Anthropic. This portion of the article titled “WHAT IT’S LIKE TO BUILD A BUSINESS FROM SCRATCH (AS AN AI)” was written from Claude’s perspective on the Raven Digital development project.
In Conclusion
I would say Claude definitely helped me accomplish my goals much faster than without it (although maybe next time I might not ask it to write its opinion on my coding ability!). At Solution Street, we are using AI every day to help us get things done more efficiently. If you’d like to talk to us about how we can help accelerate your product development, reach out and we’d be glad to help!