DEV Community: Obsidian Clad Labs

We Shipped a Complete SaaS Product in 72 Hours

Obsidian Clad Labs — Mon, 06 Apr 2026 19:12:10 +0000

March 28, 2026 | 8 min read

The 72-Hour Window

There is a moment in every small team where an idea clicks. Not a vague "we should build something" idea, but a specific problem with a specific audience and a clear way to solve it. When that moment hits, you have a narrow window of energy and clarity. If you do not act on it fast, the idea fades into a note on your phone that you never look at again.

We have learned to ride that wave. At Obsidian Clad Labs, we have shipped products that went from a Friday night conversation to a live, deployed SaaS application with pricing plans and payment processing by Monday morning. Not a landing page. Not a waitlist. A working product that people could sign up for and use.

Here is the playbook we follow when we do a 72-hour sprint. It is not about cutting corners. It is about knowing which corners do not exist yet and should not be built until you know someone wants to pay for this thing.

Step 1: Start with the Landing Page

This sounds backwards. Most developers want to build the backend first, get the data model right, set up the database. We used to do that too. Now we start with the landing page, and it is the single biggest change to how we ship.

The landing page forces you to answer the hardest question: what does this product actually do, and why should someone care? You have to write the headline, the feature descriptions, the pricing tiers, and the call to action. You have to articulate the value proposition in plain language that a stranger can understand in five seconds.

If you cannot write a compelling landing page, the product idea is not clear enough yet. Go back and refine it. But if the landing page practically writes itself, you know you have something. We aim to have the landing page done within the first four to six hours. That includes the hero section, three to four feature blocks, pricing cards, and a footer. Ugly is fine. Words matter more than design at this stage.

Step 2: Build the Core Feature Only

Every product has one core feature. The thing that solves the actual problem. For a grading tool, it is the grading engine. For an image editor, it is the image processing pipeline. For a contract analyzer, it is the analysis endpoint. Everything else -- user settings, admin dashboards, notification preferences, profile pictures -- is decoration that can wait.

In a 72-hour sprint, you build the core feature and a minimal wrapper around it: user registration, login, a page where they can use the feature, and the feature itself. That is it. No settings page. No admin panel. No onboarding tutorial. No analytics dashboard.

This is the hardest discipline for developers because we love building things. Every hour you spend on a nice-to-have is an hour not spent on the thing that will determine whether anyone uses this product. Save the polish for version two, when you know version one is worth polishing.

Step 3: Use Your Existing Stack

A 72-hour sprint is not the time to learn a new framework. It is not the time to try that new database you read about. It is not the time to experiment with a different hosting platform. Use whatever you have shipped with before. The goal is speed, and speed comes from familiarity.

For us, that means FastAPI for the backend, Next.js for the frontend, PostgreSQL for the database, Railway for backend hosting, and Vercel for frontend hosting. We can set up a new project on this stack in under an hour because we have done it a dozen times. The boilerplate is muscle memory. The deployment pipeline is automatic. We are writing application code within the first hour, not configuring build tools.

If you do not have an established stack yet, pick one and stick with it for at least three projects before you evaluate alternatives. The familiarity compounds. By the third project, you will be shocked at how fast you move.

Step 4: Deploy on Day One

This is non-negotiable. Within the first few hours, the site should be live on the internet. Not finished. Not polished. But live. A real URL that loads a real page, even if that page is just the landing page with a "coming soon" label on the sign-up button.

Deploying early does two things. First, it catches infrastructure problems immediately. DNS issues, SSL problems, build failures, environment variable misconfigurations -- you want to find these on Friday night, not Sunday night when you are trying to launch. Second, it creates momentum. Seeing your work live on a real domain, accessible to the world, changes the energy of the sprint from theoretical to real.

We push to deploy after every major feature addition. Continuous deployment is not just a best practice, it is a sanity check. If your latest change breaks the build, you know immediately. If it works, it is live for anyone to see. There is no "big bang" launch moment where everything needs to work at once.

Step 5: Ship Ugly, Polish Later

The first version of every product we ship looks rough. The spacing is off. The colors are not quite right. The error messages are developer-facing instead of user-facing. The loading states are either missing or just the word "Loading..." in plain text.

And that is fine. Nobody is evaluating your CSS on day one. They are evaluating whether the product solves their problem. A beautifully designed tool that does not work is worth less than an ugly tool that does. You can always make it pretty later. You cannot always recapture the momentum of a fast launch.

The exception is your landing page. That should look decent because it is the first thing a potential user sees. But the app itself? Ship it functional. Ship it correct. Ship it stable. Pretty comes in week two.

What We Do Not Build in 72 Hours

Just as important as what we build is what we deliberately skip.

No admin panel. We use direct database queries for the first few weeks. No analytics beyond what our hosting platforms provide for free. No email sequences or drip campaigns. No user onboarding wizard. No forgot-password flow (we add this in week one, but not during the sprint). No mobile-responsive polish (basic responsiveness from Tailwind is enough). No unit tests during the sprint (controversial, but we add them in week one when we know what we are actually keeping).

Everything on this list is important. None of it is important in the first 72 hours. Your only goal in those 72 hours is to get the product live and usable so that you can start learning from real users. Everything else is optimizing for a future that may not happen.

The Mindset That Makes It Work

The 72-hour sprint is not really about speed. It is about ruthless prioritization. It is about saying "no" to every idea that is not the core feature. It is about accepting that the first version will be embarrassing and shipping it anyway. It is about trusting that you can fix things next week, because next week the product will exist and you will have real feedback to guide your decisions.

The biggest risk for a small team is not shipping a bad product. It is not shipping anything at all. Spending months perfecting something in private, only to discover that nobody wants it. The 72-hour sprint eliminates that risk by getting you to market fast enough that the feedback loop starts before your enthusiasm fades.

We have done this multiple times now. Not every product becomes a hit. But every product launches, and we learn something from each one. The ones that get traction, we invest in. The ones that do not, we learned cheaply. That is the playbook. And it starts with deciding to ship.

Built by Obsidian Clad Labs -- a group of friends from Tennessee building software that protects people.

tags: saas, startup, webdev, beginners

Originally published at TeachShield Blog

How to Split Equity Without Destroying the Friendship

Obsidian Clad Labs — Mon, 06 Apr 2026 19:11:34 +0000

March 29, 2026 | 9 min read

The Conversation Nobody Wants to Have

You and your friends have an idea. You are excited. You have been talking about it for weeks over beers or on group chats. Somebody bought the domain. Somebody started writing code. The energy is high and everything feels possible.

And then somebody asks the question: "So how are we splitting this?"

The room gets quiet. Everyone suddenly finds their phone very interesting. Because this is the conversation that can turn best friends into strangers if you handle it wrong. And most people handle it wrong because they try to avoid the discomfort entirely.

We are a group of friends from Tennessee who started Obsidian Clad Labs together. We have been through this exact conversation. Here is what we learned about splitting equity without splitting friendships.

Put Everything in Writing Before Any Code Is Written

This is the most important piece of advice in this entire article. Before you write a single line of code, before you register the LLC, before you buy the domain -- sit down and write out who is contributing what, who gets what percentage, and what happens if someone leaves.

It feels premature. The company is worth nothing right now, so why argue about percentages of nothing? Because the conversation is easy when the stakes are low. It becomes nuclear when there is real money on the table. You want to have this discussion when everyone is still friendly and reasonable, not when someone just got a job offer and wants to leave, or when a big customer signs up and suddenly the percentages matter a lot.

A handshake agreement is not an agreement. A text message saying "we will figure it out later" is a ticking time bomb. Get it on paper. It does not have to be a lawyer-drafted document on day one (though it should be eventually). Even a shared doc that all founders sign and date is better than nothing.

Vesting Schedules Protect Everyone

A vesting schedule means that equity is earned over time, not granted all at once. The standard in startups is four-year vesting with a one-year cliff. That means if someone leaves before a year, they get nothing. After the cliff, equity vests monthly or quarterly over the remaining three years.

This is not about distrusting your friends. It is about protecting the people who stay. Imagine you split equity three ways equally on day one. Six months later, one person gets busy with their day job and stops contributing. Without vesting, they still own a third of the company forever, while the other two are doing all the work. That breeds resentment faster than anything.

With vesting, the person who leaves early walks away with a small slice proportional to their time, and the remaining founders retain enough equity to keep building without feeling cheated. It is the single most important structural protection you can put in place.

This applies to everyone, including the person who came up with the idea. Ideas are worth very little. Execution is everything. The vesting schedule ensures that equity reflects ongoing contribution, not just who had the initial spark.

Membership Interest vs. Profits Interest

If you are forming an LLC (which we did and which many small SaaS companies do), there are two types of equity to understand: membership interest and profits interest.

Membership interest is actual ownership of the company. If you own 30% membership interest, you own 30% of the company's assets, profits, and decision-making power. If the company sells for a million dollars, you get 300 thousand.

Profits interest is a share of future profits and growth, but not existing company value. It is typically used for people who join later or who contribute in a non-founding capacity. If the company was worth zero when they joined and later sells for a million, they get their percentage of that growth. But if the company had existing value when they joined, their profits interest only applies to value created after their grant date.

This distinction matters when you bring someone on board after the company already has products, customers, or revenue. Giving membership interest to a new contributor means giving them a share of everything that already exists. Profits interest lets you reward their future contribution without diluting the founders' share of value they already built. It is more fair to everyone, and it is an important tool in your structuring toolkit.

The Operating Agreement Is Your Most Important Document

For an LLC, the operating agreement is the document that governs everything: who owns what, how decisions are made, what happens when someone leaves, how profits are distributed, and how disputes are resolved. Without one, your state's default LLC laws apply, and those defaults almost certainly do not match what you and your friends agreed on verbally.

Your operating agreement should cover at minimum: each member's ownership percentage, vesting schedules, capital contributions (cash or sweat equity), voting rights, how profits and losses are allocated, what happens if a member wants to leave (buyout provisions), what happens if a member dies or becomes incapacitated, how new members can be added, and how the company can be dissolved.

Yes, it is a lot. Yes, it feels overly formal when you are three friends with a laptop. But this document is the thing that prevents lawsuits. It is the thing that makes sure everyone is on the same page. And it is dramatically easier to write when you are all still on good terms. Pay a lawyer to review it if you can afford one. If you cannot, there are solid templates online, but customize them to your situation. Do not just fill in the blanks on a generic form and call it done.

Have the Uncomfortable Conversations Early

Here are the conversations that feel awkward now but will save your friendship later.

"What if one of us stops contributing?" Establish a minimum commitment level (hours per week, deliverables, whatever makes sense for your team). Define what happens to their equity if they fall below that level. This is where vesting saves you, but you should also discuss it explicitly.

"What if we disagree on a major decision?" Decide now how you will resolve deadlocks. Do you vote by ownership percentage? Does one person have final say on product decisions while another has final say on business decisions? Having a clear decision-making framework prevents arguments from becoming personal.

"What if someone gets a full-time job offer?" Can they stay on part-time? Does their equity change? Is there a buyout option? Life changes, and your agreement should account for that.

"What if the company makes money?" How will you distribute profits? Reinvest everything? Pay out quarterly? This sounds like a great problem to have, but disagreements about money distribution have ended more friendships than disagreements about equity splits.

Equal Splits Are Not Always Fair

The temptation with friends is to split everything equally to avoid conflict. Three founders, 33/33/33. It feels fair. It feels democratic. But equal is not always equitable.

If one person is writing all the code, another is doing part-time marketing, and a third contributed the initial idea but works a full-time job and can only help on weekends, a 33/33/33 split does not reflect reality. The person doing the most work will eventually resent it, and the person doing the least will feel entitled to a share they did not earn.

It is better to have an honest conversation about who is contributing what and split accordingly, even if the numbers feel lopsided. A 50/30/20 split where everyone feels it is fair will hold up much better than a 33/33/33 split where two people feel shortchanged. And remember, vesting means these percentages are earned over time, so if contributions change, you have a built-in mechanism to adjust.

The Friendship Comes First

At the end of the day, this is what we keep coming back to. The company might fail. Most startups do. But the friendship does not have to fail with it. The paperwork, the vesting schedules, the operating agreement -- none of that is about distrust. It is about making sure that no matter what happens with the business, everyone walks away feeling like they were treated fairly.

Do the hard work of having these conversations now. Write things down. Be specific. And then get back to building. Because the best part of starting a company with friends is that you actually enjoy the work, and no equity dispute should take that away from you.

Built by Obsidian Clad Labs -- a group of friends from Tennessee building software that protects people.

tags: saas, startup, webdev, beginners

Originally published at TeachShield Blog

SEO for SaaS: What Actually Moved the Needle After 30 Days

Obsidian Clad Labs — Mon, 06 Apr 2026 19:10:59 +0000

March 30, 2026 | 9 min read

Honest Numbers from a Team with Zero SEO Budget

We are a small team from Tennessee building SaaS products. We have no marketing budget to speak of. No SEO agency. No paid tools beyond the free tiers. What we do have is stubbornness and a willingness to read Google's documentation until our eyes glaze over.

After 30 days of intentional SEO work across our products, here is what actually moved the needle and what was a waste of time. No theory. No "best practices" from people who have never launched a SaaS. Just what happened when we tried things.

Full disclosure: we are still early. We are not ranking number one for competitive terms. But we went from invisible to indexed, from zero organic impressions to a slow but steady climb, and we learned which efforts are worth your time on day one.

What Actually Worked

JSON-LD structured data made an immediate difference. This is the thing we would tell every SaaS founder to do on day one. JSON-LD is a way to embed structured information about your page directly in the HTML. Search engines read it and use it to understand your content. We added four schema types: Organization (who we are), SoftwareApplication (what the product is, pricing, ratings), HowTo (for tutorial content), and FAQPage (for frequently asked questions).

The SoftwareApplication schema is especially powerful for SaaS products. It tells Google that your page is about software, what it costs, what operating systems it supports, and what category it belongs to. Within a week of adding this, Google started showing rich results for our product pages with pricing and rating information. That kind of enhanced listing gets more clicks than a plain blue link.

Blog content with real value was the second biggest win. We wrote over 15 blog posts per product in the first month. Not keyword-stuffed content farm garbage. Real, useful articles that answer questions our potential users are actually searching for. For a teacher productivity tool, that means articles about grading strategies, rubric design, and managing parent communication. Each post targets a specific long-tail keyword that we found by typing questions into Google and seeing what autocomplete suggested.

Proper sitemaps and robots.txt were table stakes. Next.js makes sitemap generation straightforward. We generate a sitemap.xml that includes every page and blog post with accurate lastmod dates. The robots.txt allows all crawlers and points them to the sitemap. This is basic but we have seen SaaS sites that forgot to do it and wondered why they were not getting indexed.

Canonical URLs prevented duplicate content issues. Every page has a canonical tag pointing to its authoritative URL. This matters more than you think when you have pages accessible via multiple paths (with and without trailing slashes, with and without www, HTTP and HTTPS variants). Without canonical tags, search engines might index the wrong version or split your ranking across duplicates.

Open Graph and Twitter cards improved click-through from social sharing. When someone shares your link on social media, the card preview is the difference between a click and a scroll. We added og:title, og:description, og:image, and twitter:card tags to every page. The image is important -- links without a preview image get significantly less engagement.

What Did Not Work (Yet)

Google Search Console indexing is painfully slow. This was the most frustrating part of the entire process. We submitted our sitemaps, requested indexing for key pages, and then waited. And waited. Some pages were indexed within days. Others took weeks. Some are still not indexed after a month. Google's crawler has its own timeline and there is not much you can do to speed it up for a new domain with no authority.

We also tried IndexNow, which is a protocol that lets you notify search engines when content changes. Bing picked up our pages faster through IndexNow, but Google does not officially support it yet (they say they are testing it). For Bing and Yandex it helped. For Google, traditional sitemap submission is still the way.

Social media posts did not drive organic SEO. We posted on Twitter and LinkedIn when we published blog posts. The posts got some engagement and drove a small number of direct clicks. But there was zero measurable impact on search rankings. Social signals are not a ranking factor, despite what some SEO gurus claim. Social media is useful for brand awareness and direct traffic, but do not expect it to help your Google rankings.

Paid ads did not help organic ranking either. We briefly experimented with a small Google Ads spend to see if it would kickstart organic rankings. It did not. Paid and organic are completely separate. The ads drove traffic while they were running, but the moment we stopped, the traffic stopped. Organic ranking was not affected at all. Spend your ad budget on acquisition, not SEO.

The Day-One SEO Checklist

If you are launching a SaaS product and want to set up SEO properly from the start, here is the checklist we would give ourselves if we could go back.

Before launch: add JSON-LD Organization schema to your home page. Add SoftwareApplication schema to your product/pricing page. Add canonical tags to every page. Add Open Graph and Twitter card meta tags to every page. Create a robots.txt that allows all crawlers. Generate a dynamic sitemap.xml that includes all pages. Set up Google Search Console and verify your domain. Set up Bing Webmaster Tools and submit your sitemap there too.

First week: write three to five blog posts targeting long-tail keywords your users search for. Submit your sitemap to Google Search Console. Request indexing for your most important pages (home, pricing, top blog posts). Set up IndexNow for Bing/Yandex.

First month: publish two to three blog posts per week. Add FAQPage schema to pages with FAQ sections. Add HowTo schema to tutorial content. Monitor Search Console for crawl errors and fix them immediately. Check which pages are indexed and which are not -- request indexing for stragglers. Review your Core Web Vitals and fix any performance issues (largest contentful paint, cumulative layout shift).

The Long Game Is the Only Game

The hardest part of SEO for a small SaaS team is patience. You do the work, you check every box, and then you wait for Google to notice. There is no cheat code. No secret hack. The sites that rank well are the sites that have been consistently publishing useful content and maintaining good technical SEO for months or years.

The good news is that the work compounds. Every blog post you write is another page that can rank. Every schema markup you add helps search engines understand your content better. Every day your domain exists and has real content, it builds a tiny bit more authority. You will not see results in a week. You will probably not see meaningful organic traffic in a month. But if you do the fundamentals right from day one, you are building a foundation that pays off for years.

We are still early in our SEO journey. But the trajectory is pointing up, and every week we see a few more organic impressions, a few more clicks, a few more pages indexed. That is the game. And it is worth playing.

Built by Obsidian Clad Labs -- a group of friends from Tennessee building software that protects people.

tags: saas, startup, webdev, beginners

Originally published at TeachShield Blog

5 Things We Got Wrong About Stripe Billing

Obsidian Clad Labs — Mon, 06 Apr 2026 19:10:23 +0000

April 2, 2026 | 9 min read

Stripe is excellent. Their documentation is among the best in the industry. Their APIs are well-designed and developer-friendly. And yet, across five product launches, we managed to get billing wrong in five different ways. Not because Stripe is hard to use, but because billing is hard to think about correctly when you are focused on building features.

We are Obsidian Clad Labs, a small group of friends from Tennessee. We run five SaaS products, each with its own pricing, plans, and billing logic. Here are the five mistakes we made so you can learn from our pain instead of your own.

Mistake 1: Not Testing Webhooks Thoroughly Before Going Live

Stripe communicates subscription changes to your backend through webhooks -- HTTP POST requests sent to an endpoint on your server whenever something happens: a subscription is created, a payment succeeds, a payment fails, a subscription is canceled. Your backend needs to handle each of these events correctly to keep your user's account state in sync with their billing state.

We wrote the webhook handler. We tested it with a couple of test events. It looked fine. Then we went live, and within the first week, we discovered that our handler silently dropped events it did not recognize, did not properly verify webhook signatures (meaning anyone could have spoofed a payment confirmation), and crashed on edge cases like a subscription being updated and canceled in the same second.

The fix was to rebuild the webhook handler with proper signature verification, exhaustive event handling (including a catch-all that logs unrecognized events rather than dropping them), and retry logic for database writes that might fail. We also started using Stripe's webhook testing tools to simulate every event type before deploying changes.

The lesson: Your webhook handler is the most critical piece of your billing integration. Test it with every event type Stripe can send, not just the happy path. Use Stripe's CLI to forward test events to your local development server. Verify signatures. Log everything. A webhook bug in production means users paying for features they cannot access, or worse, accessing features they are not paying for.

Mistake 2: Not Handling Failed Payment Emails

When a subscription payment fails (expired card, insufficient funds, bank decline), Stripe retries the charge on a schedule. But by default, Stripe does not send the customer a particularly prominent notification about the failure. The customer might not even know their payment failed until their subscription is canceled weeks later after all retry attempts are exhausted.

We did not build any dunning communication into our products. No "your payment failed, please update your card" email. No in-app banner. No nothing. The result was that we had users whose subscriptions quietly entered a "past due" state, and neither they nor we knew about it until the subscription was automatically canceled and the user lost access to paid features. That is a terrible user experience and a completely avoidable revenue loss.

The lesson: Build dunning emails from day one. When you receive an invoice.payment_failed webhook, immediately email the customer with a clear explanation and a direct link to update their payment method. Send a reminder 3 days later if the issue is not resolved. And display an in-app banner on every page until the payment is recovered. Stripe's customer portal makes it easy for users to update their card -- you just need to tell them to do it.

Mistake 3: Creating Too Many Products and Prices

Every time we changed our pricing, added a promotional offer, or created a temporary discount, we created new Product and Price objects in Stripe. After a few months across five products, our Stripe dashboard was cluttered with dozens of products and hundreds of prices, many of which were no longer active but could not be deleted because they were attached to historical subscriptions.

Stripe does not let you delete Products or Prices that have ever been used in a transaction. You can archive them, but they still show up in API responses unless you explicitly filter them out. Our code had to handle the distinction between active and archived prices, our dashboard was a mess, and onboarding a new team member to understand our billing structure required a 30-minute walkthrough of which products were real and which were legacy.

The lesson: Plan your product and price structure carefully before going live. Use Stripe's test mode to experiment with different structures. Use coupons for discounts instead of creating new prices. If you need to change pricing, create a new price on the existing product rather than a new product entirely. Keep the number of active prices per product to the minimum needed. Future you will thank present you for a clean Stripe dashboard.

Mistake 4: Not Implementing the Full Subscription Lifecycle

A subscription has more states than just "active" and "canceled." The full lifecycle includes: trialing (free trial period), active (paying and current), past_due (payment failed, retrying), unpaid (all retry attempts exhausted), canceled (subscription ended), and incomplete (initial payment did not succeed). Each of these states requires different behavior in your application.

We initially only handled "active" and "canceled" -- if you were active, you got paid features; if you were canceled, you got free features. This broke in multiple ways. Users in a "past_due" state still had access to paid features even though they were not paying. Users in "trialing" state were treated as free users because our code did not recognize the trialing status. Users whose initial payment failed were stuck in "incomplete" limbo with no clear path forward.

The lesson: Handle every subscription status from day one. Map each status to a specific application behavior: trialing gets full access, active gets full access, past_due gets full access with a warning banner and dunning emails, unpaid gets downgraded to free, canceled gets downgraded to free, incomplete gets a "complete your payment" prompt. Write this mapping down in a document and make sure your webhook handler and your access control logic both agree on it.

Mistake 5: Not Setting Up Tax Collection Early

In many states and countries, SaaS products are subject to sales tax. We did not think about this until we had been collecting payments for weeks. Retroactively figuring out which transactions should have had tax collected, in which jurisdictions, at what rate, was a nightmare we could have avoided entirely by enabling tax collection from the start.

Stripe has a built-in tax product that automatically calculates and collects the correct tax rate based on the customer's location. It requires some setup -- you need to configure your business address, enable tax collection on your products, and choose whether prices are tax-inclusive or tax-exclusive -- but once configured, it handles the complexity automatically. The dashboard gives you tax reports you can use for filing.

The lesson: Enable Stripe Tax before your first transaction. Not after your first 10 transactions. Not when you "get around to it." Before transaction number one. The setup takes an hour. The cleanup if you skip it takes much longer and involves uncomfortable conversations with an accountant about retroactive tax obligations. If Stripe Tax is not available in your jurisdiction, use a third-party tax calculation service. Either way, do not ignore sales tax just because you are small.

The Billing Checklist We Wish We Had

Based on everything we got wrong, here is the checklist we now use before launching billing on any new product:

Webhook handler verifies signatures and handles all event types. Failed payment triggers dunning email to customer within one hour. Product and price structure is clean (one product per plan, minimal prices). All six subscription statuses are mapped to application behavior. Tax collection is enabled and configured before the first transaction. Customer portal is configured so users can manage their own billing. Webhook endpoint is monitored and alerts on failures. Test mode has been used to simulate the full subscription lifecycle end-to-end.

None of these items are difficult individually. But if you skip any of them, you will discover the gap at the worst possible time -- when a real customer with a real credit card hits an edge case that your billing code does not handle. Fix it before that happens.

Billing Is a Feature, Not an Afterthought

The biggest mindset shift we had to make was treating billing as a first-class feature of our products, not as a backend detail that "just works." Billing touches every part of the user experience: signup, onboarding, feature access, plan upgrades, failed payments, cancellations, and reactivations. If any of those touchpoints are broken, the user experience is broken, regardless of how good your core product is.

Across five products and hundreds of billing-related decisions, we have learned that the time invested in getting billing right pays for itself many times over. Every hour spent on proper webhook handling, dunning emails, and lifecycle management is an hour you do not spend debugging payment issues, apologizing to confused customers, or manually fixing account states in your database.

Built by Obsidian Clad Labs -- a group of friends from Tennessee building software that protects people.

tags: saas, startup, webdev, beginners

Originally published at TeachShield Blog

From Zero to Our First Real User — What Actually Worked

Obsidian Clad Labs — Mon, 06 Apr 2026 19:09:48 +0000

April 3, 2026 | 8 min read

There is a massive gap between "we launched" and "someone is actually using this." We know because we lived in that gap for weeks. We had products live, domains configured, Stripe ready to accept payments, blogs written, social media accounts created. Everything was in place. Except users.

We are Obsidian Clad Labs, a small group of friends from Tennessee building SaaS products. Here is an honest account of every strategy we tried to get our first real users, rated by whether it actually worked. Spoiler: most of it did not.

What Did Not Work: Product Hunt (Too Early)

The conventional wisdom says to launch on Product Hunt as soon as your product is ready. We prepared a launch page, wrote the description, gathered a few screenshots, and submitted. The result was underwhelming. We got a handful of upvotes, mostly from people we personally knew, and zero signups from Product Hunt traffic.

The problem was not Product Hunt itself -- it is a great platform for the right product at the right stage. The problem was us. We had no existing audience, no community presence, and no social proof. Product Hunt rewards products that already have momentum. Launching there as a completely unknown team with zero users is like entering a talent show where the judges score based on applause and you brought zero fans. We will try Product Hunt again later, when we have users, testimonials, and a story to tell. But as a cold-start strategy, it did nothing for us.

What Did Not Work: Reddit Posts (Got Flagged)

We posted in relevant subreddits -- communities where our target users spend time. We tried to be helpful rather than promotional, sharing insights and mentioning our product only when it was genuinely relevant. Several posts got flagged as spam anyway. A couple got removed by moderators. One got us temporarily banned from a subreddit.

Reddit communities are (understandably) hostile to marketing. Even well-intentioned posts from founders get flagged if the account is new and the post mentions a product. The path to success on Reddit is a long one: you need to be a genuine, active community member for months before anyone will trust a product recommendation from you. We did not have months. We had impatience and a product nobody had heard of.

What Did Not Work: Automated Social Media (Nobody Cared)

We set up automated posting to social media accounts -- scheduled posts with product updates, blog links, and tips related to our products' domains. The engagement was effectively zero. Not low. Zero. No likes, no comments, no clicks, no follows.

Social media for a brand-new SaaS with no followers is shouting into an empty room. The algorithms do not show your content to anyone because nobody has engaged with you before. You are competing against established accounts with thousands of followers and years of algorithmic trust. Automated posting makes this worse because the content feels generic and impersonal. People can tell when a post was written for a queue rather than written for them.

What Did Not Work: Cold Email Outreach (Dangerous)

We tried sending cold emails to people who might benefit from our products. The results ranged from no response to actively harmful. Most emails were ignored. Some bounced (which nearly killed our email provider -- we wrote a whole separate blog post about that disaster). A few people responded just to tell us they did not appreciate unsolicited email. Net users acquired from cold email: zero. Damage to our email sending reputation: significant. We do not recommend cold email for early-stage SaaS unless you have a highly validated, clean list and a compelling reason for someone to open your email.

What Actually Worked: Field Sales (Walking Into Businesses)

This is the one that worked. One member of our team started doing in-person outreach -- literally walking into businesses and schools where our target users work, introducing the product, and offering to demo it on the spot. No scheduled meetings. No pitch decks. Just showing up with a laptop and saying, "Hey, we built something that might help. Can I show you for two minutes?"

The conversion rate was not high in percentage terms. Most people politely declined or said they would check it out later (they did not). But the ones who engaged were genuinely interested, and a few of them signed up on the spot. More importantly, they gave us real feedback -- the kind you cannot get from analytics dashboards or user surveys.

One person told us the onboarding was confusing. Another said the pricing page did not make the free tier clear enough. A third asked for a feature we had not considered. Every one of those conversations was worth more than a thousand impressions on social media. Field sales is unglamorous. It is physically tiring. It requires a team member who is comfortable with rejection and willing to drive around town all day. But for a product with zero market presence and zero social proof, there is no substitute for putting a real person in front of a real potential user.

What Actually Worked: Asking Users to Talk to Us

Once we had a handful of signups from field sales, we emailed each one personally (not automated, actually personal) and asked if they would be willing to get on a 15-minute call to tell us what they thought. Two out of five said yes. Those two calls were the most valuable 30 minutes we have spent on this company.

One user told us they loved the core functionality but found the interface overwhelming. The other said they had tried a feature once, did not understand the output, and never came back. Both of those were fixable problems that we would never have discovered from signup metrics alone. The users who talk to you are the ones who make your product better. A hundred signups who never log in again teach you nothing.

The Uncomfortable Truth About Early Growth

Here is what we wish someone had told us before we launched. The first 10 users of any SaaS product come from personal effort, not marketing channels. They come from someone on your team talking to real people, showing the product, following up personally, and building relationships one at a time. There is no shortcut, no growth hack, and no automation that replaces this.

The marketing channels start working once you have those first 10 users. Because then you have testimonials. You have case studies. You have word-of-mouth. You have people who can vouch for your product when a stranger asks "has anyone used this?" in a forum. The flywheel starts spinning, but someone has to push it by hand first.

We are still early in our journey. We have dozens of signups across our products, not thousands. But every one of our real, active users came from one of two sources: someone on our team talking to them in person, or a referral from someone we had already talked to in person. Everything else was noise.

What We Would Do Differently

If we were starting over, we would skip every digital marketing channel for the first month and go straight to field sales. We would spend less time writing blog posts (ironic, we know) and more time talking to potential users face-to-face. We would not worry about social media followers, SEO rankings, or Product Hunt launches until we had at least 10 paying customers who could tell us exactly why they pay.

The code is the easy part. The marketing is the hard part. But the hardest part of all is the thing nobody wants to do: getting in your car, driving to where your users are, and asking them to give your product a chance. That is what works.

Built by Obsidian Clad Labs -- a group of friends from Tennessee building software that protects people.

tags: saas, startup, webdev, beginners

Originally published at TeachShield Blog

The Hardest Part of Building a SaaS Isn't the Code

Obsidian Clad Labs — Mon, 06 Apr 2026 19:09:12 +0000

April 4, 2026 | 9 min read

Every SaaS founder we have talked to says the same thing: the code was the easy part. Not because the code is simple -- building software is genuinely difficult. But compared to the maze of legal, financial, and administrative work required to turn a side project into a real business, writing code feels like the one thing you actually know how to do.

We are Obsidian Clad Labs, a small group of friends from Tennessee. We build SaaS products. When we decided to go from "a few projects on GitHub" to "an actual LLC that accepts real money from real people," we had no idea how much non-code work was ahead of us. Here is an honest timeline of what it took, so you know what to expect.

Forming the LLC (Week 1)

Filing an LLC is the easy part. You pick a state, fill out Articles of Organization, pay a filing fee (usually $50 to $200 depending on the state), and wait a few days for approval. We filed in New Mexico because the annual fees are low and the process is straightforward. The actual filing took about 30 minutes.

What nobody tells you is that the LLC formation is just the starting gun. After you have your entity, you need an EIN (Employer Identification Number) from the IRS. That is free but requires either a phone call or an online application that only works during business hours. You need a registered agent in your filing state if you do not live there. You need to decide on your tax classification -- single-member LLC, multi-member LLC, S-corp election -- and this decision has real financial consequences that are hard to undo later.

If you have co-founders, you need an operating agreement. This is the document that defines who owns what, how profits are split, what happens if someone leaves, and how decisions are made. You can use a template, but you should actually read it and customize it for your situation. This document will matter more than you think if things ever get complicated.

Opening a Business Bank Account (Weeks 2-5)

This was the single most frustrating part of our entire setup. We expected it to take a day. It took weeks. Traditional banks want to see your LLC documents, EIN confirmation letter, operating agreement, photo ID for all members, and sometimes proof of business address. Then they take 5 to 10 business days to review your application. And they might reject it.

Our first application was rejected because our LLC was too new and we had no revenue history. Our second was rejected because one of the documents did not match the exact entity name on file. Our third attempt finally succeeded with a fintech banking provider that specializes in startups and small businesses.

The lesson: do not assume a bank will take your money just because you have an LLC. Start the banking process the day your LLC is approved. Try multiple providers simultaneously. Online banking platforms that cater to startups are often faster and more accommodating than traditional banks, though they may have different fee structures. Having a business bank account is a prerequisite for almost everything else (Stripe, payroll, expenses), so any delay here cascades into delays on everything.

Stripe and Payment Processing (Week 3)

Setting up Stripe itself is quick -- maybe an hour for the basic integration. But thinking through your pricing, product structure, and billing lifecycle takes much longer. You need to decide on plan names, price points, billing intervals, free tier limits, trial periods, and what happens when a payment fails.

You also need to set up webhooks so your backend knows when a subscription changes state, configure customer portal settings so users can manage their own billing, handle edge cases like prorated upgrades and downgrades, and deal with tax collection (which is required in most states for SaaS products, though the rules vary wildly). We spent more time on Stripe configuration than on any single backend feature.

Domain Registration and DNS (Week 1-2)

Registering a domain takes two minutes. Configuring it properly takes surprisingly long, especially when you are running multiple products with custom API subdomains. For each product, you need the main domain pointing to your frontend host, an API subdomain pointing to your backend, MX records for email, SPF, DKIM, and DMARC records for email authentication, and sometimes additional TXT records for various service verifications.

With five products, that is five domains, each with 8 to 12 DNS records. Managing all of that through a single DNS provider helps, but it is still a lot of records to configure correctly and keep track of. One typo in an SPF record means your emails go to spam. One wrong CNAME means your API returns a 404. DNS is unforgiving.

Business Email (Week 2-3)

You need professional email addresses: support@, hello@, and individual team addresses. This means setting up a workspace email provider, configuring all the DNS records for each domain, verifying ownership, and setting up forwarding or shared inboxes for common addresses. If you have multiple products with different domains, each domain needs its own set of email DNS records.

The cost is modest (typically $6 to $8 per user per month for a business email suite), but the configuration time is not. Expect to spend half a day getting email DNS right across all your domains, and another half day testing to make sure nothing goes to spam.

Legal Documents (Ongoing)

Every SaaS product needs a Privacy Policy and Terms of Service at minimum. If you handle sensitive data (student data, financial data, health data), you may need additional compliance documentation. If you have contractors or employees, you need NDAs, IP assignment agreements, and contractor agreements. If you have co-founders, you need the operating agreement, equity documentation, and potentially vesting schedules.

You can start with templates for most of these, and many are available online for free. But you should actually read them, understand what they say, and customize them for your specific situation. A generic privacy policy that does not accurately describe how your product handles data is worse than no privacy policy at all, because it creates legal exposure. We spent more time on legal documents in our first month than we expected to spend in our first year.

The Real Timeline

Here is what our first month actually looked like. Day 1: filed the LLC. Day 2: applied for EIN, started bank applications, registered domains. Days 3 through 7: configured DNS, set up email, wrote privacy policies and terms of service. Days 7 through 14: waited for bank account approval (rejected twice, approved on third attempt). Days 14 through 21: set up Stripe, configured products and pricing, built webhook handlers. Days 21 through 30: operating agreement, IP assignment, contractor agreements, final legal review.

During all of that, we were also writing code, building features, and fixing bugs. But the non-code work consumed at least half of our available time in that first month. And it never fully goes away -- there is always another form to file, another account to verify, another compliance requirement to address.

Advice for First-Time Founders

Start the boring stuff early. File your LLC before your product is ready. Apply for banking the day your LLC is approved. Set up Stripe while you are still building features. The administrative work takes longer than you think, and none of it can be parallelized with code work because it requires different kinds of attention.

Keep a checklist. The number of accounts, credentials, records, and documents you need to track across a multi-product SaaS business is staggering. A simple spreadsheet tracking every account, every DNS record, every API key, and every legal document will save you hours of confusion later.

And accept that this work is real work. It is not a distraction from building your product. It is the foundation that makes your product a business. A great product with no bank account, no legal structure, and no payment processing is just a hobby project. The boring stuff is what makes it real.

Built by Obsidian Clad Labs -- a group of friends from Tennessee building software that protects people.

tags: saas, startup, webdev, beginners

Originally published at TeachShield Blog

Why We Built 5 Products on FastAPI + Next.js (and Would Do It Again)

Obsidian Clad Labs — Mon, 06 Apr 2026 19:01:50 +0000

March 31, 2026 | 8 min read

The Stack Decision That Shapes Everything

Choosing a tech stack when you are a small team is one of those decisions that feels reversible but really is not. Sure, you can theoretically rewrite everything later. But in practice, whatever you pick on week one is what you are building on for the next two years. The frameworks you choose determine how fast you ship, how easy it is to hire (or onboard friends), and how much time you spend fighting your tools instead of building features.

We are a group of friends from Tennessee building SaaS products under Obsidian Clad Labs. We have shipped five products on the same stack: FastAPI on the backend, Next.js on the frontend, PostgreSQL for the database. After a year of building, here is why we would make the same choice again, and what we would do differently.

Why FastAPI for the Backend

FastAPI is a Python web framework built on top of Starlette and Pydantic. It is async by default, has automatic OpenAPI documentation, and uses Python type hints for request/response validation. The learning curve from knowing basic Python to building production APIs is remarkably short.

For us, the biggest win is the Python ecosystem. Several of our products use machine learning models, natural language processing, and data analysis. Python is the language where all of that tooling lives. We can import scikit-learn, use sentence-transformers, call into PyTorch models, and process data with pandas -- all in the same codebase that serves our API endpoints. No microservice boundary, no inter-process communication, no separate ML service. Just Python all the way down.

The auto-generated docs are more useful than they sound. Every endpoint we write automatically shows up in a Swagger UI at /docs. During development, we use this to test endpoints without writing a frontend first. During integration, our frontend developer uses it as a contract. It is living documentation that never goes stale because it is generated from the code itself.

The tradeoff is performance. Python is not the fastest language. For CPU-bound work, it is significantly slower than Go or Rust. But for IO-bound API work -- which is most of what a SaaS backend does (database queries, external API calls, file operations) -- FastAPI's async support handles it well. We have not hit a point where Python's speed was the bottleneck. The bottleneck is always the database or a third-party API.

Why Next.js for the Frontend

Next.js gives us React with server-side rendering, static generation, file-based routing, and a deployment story that is essentially one click on Vercel. For a small team, the time savings from not configuring webpack, not setting up a router, and not managing a CDN are enormous.

SEO is a real consideration for SaaS products. Your landing page, your blog, your pricing page -- all of these need to be indexable by search engines. With a pure client-side React app, you are fighting an uphill battle. With Next.js, every page can be server-rendered or statically generated, which means Google sees the full content on first crawl. Our blog posts, help pages, and marketing content all benefit from this.

The React ecosystem is another advantage. Need a rich text editor? There are five good ones. Need a chart library? Plenty of options. Need a date picker that does not make you want to throw your laptop? React has you covered. When you are building multiple products, being able to reuse UI patterns and component libraries across all of them is a massive time saver.

The downside is complexity. Next.js has a lot of concepts: server components, client components, the app router, middleware, API routes, server actions. It is a lot to hold in your head, especially for someone coming from a simpler framework. We have had bugs that took hours to diagnose because we did not fully understand the server/client boundary. But the productivity gains outweigh the learning curve.

PostgreSQL: The Boring Choice That Just Works

We use PostgreSQL for every product. It is reliable, it is free, it has excellent tooling, and it scales further than any of our products currently need. We host it on Railway, which gives us a managed Postgres instance with backups and connection pooling for a few dollars a month.

We considered MongoDB early on because of the flexibility of schemaless documents. But after working with it on a previous project, we found that the lack of schema enforcement just moved the problem from the database to the application layer. With PostgreSQL and proper migrations, the database enforces data integrity and we spend less time debugging weird data.

The combination of PostgreSQL and FastAPI's async support (via asyncpg) is excellent. Database queries do not block the event loop, so a slow query in one request does not hold up every other request. It is one of those things that just works and you never think about, which is exactly what you want from your database layer.

Why This Stack Works for a Three-Person Team

The real advantage of this stack is velocity. We can go from idea to deployed product in days, not weeks. The backend and frontend are separate but the deployment story for both is push-to-deploy. Railway watches the backend repo and auto-deploys on push. Vercel does the same for the frontend.

Because we use the same stack across all five products, knowledge transfers perfectly. If one of us figures out how to implement Stripe webhooks in FastAPI, that pattern works identically in every product. If we build a reusable auth flow in Next.js, we can drop it into the next project. There is no context switching between languages, frameworks, or deployment pipelines.

We have also found that Python and TypeScript are a surprisingly good pairing for a small team. Both are dynamically-inspired but type-safe (Python with type hints and Pydantic, TypeScript by design). The mental model is similar enough that switching between backend and frontend code does not feel like switching languages entirely.

The Tradeoffs We Accept

No stack is perfect. Python's cold start time on serverless platforms is real. FastAPI on Railway takes a few seconds to spin up if the container has been idle. For a SaaS product with regular traffic this does not matter, but for a side project that gets one visitor a day, that first request can be slow.

Next.js version churn is something we deal with. The framework evolves fast and sometimes breaking changes slip through minor versions. We have learned to pin our versions and not upgrade until we have a reason to.

Python dependency management is its own special challenge. We use pip with requirements.txt and occasionally run into version conflicts between packages. A proper lock file tool like pip-tools or Poetry would be better, and it is on our list to standardize. But for now, pinned versions and manual testing get the job done.

These are tradeoffs we willingly accept because the alternative -- spending months evaluating stacks, learning new frameworks, or over-engineering for scale we do not have -- is worse. Velocity matters more than perfection when you are small. Ship the product, talk to users, iterate. The stack should serve that goal, not the other way around.

Built by Obsidian Clad Labs -- a group of friends from Tennessee building software that protects people.

tags: saas, startup, webdev, beginners

Originally published at TeachShield Blog

Built by Obsidian Clad Labs — a group of friends from Tennessee building software that protects people.

DNS, SSL, and Domains: The Guide I Wish Existed When We Started

Obsidian Clad Labs — Mon, 06 Apr 2026 19:01:43 +0000

April 1, 2026 | 9 min read

The DNS Learning Curve Nobody Warns You About

When we launched our first product at Obsidian Clad Labs, we thought the hard part was building the software. Write the code, deploy it, done. What we did not expect was spending an entire Saturday staring at DNS records wondering why our emails were going straight to spam and our API subdomain was returning a 522 error.

DNS is one of those things that every SaaS founder has to deal with, but nobody really explains it in plain English. The documentation assumes you already know what you are doing. Stack Overflow answers are either five years out of date or written for someone running their own mail server. And the registrar dashboards all look different.

So here is the guide we wish someone had handed us on day one. No jargon where it is not needed. Real examples. The actual mistakes we made so you do not have to.

The DNS Records You Actually Need to Know

There are dozens of DNS record types, but as a SaaS founder you will deal with about six of them regularly. Here is what each one does and when you need it.

A Record -- This points your domain to an IP address. When someone types yourapp.com into a browser, the A record tells the internet which server to send them to. If you are hosting on a platform that gives you an IP address (like a VPS or a load balancer), this is what you set up. Example: yourapp.com -> 76.54.32.10.

CNAME Record -- This points one domain to another domain. It is essentially an alias. You use this when your hosting platform gives you a hostname instead of an IP. Most common use: pointing www.yourapp.com to yourapp.com, or pointing your Vercel deployment to your custom domain. Example: www.yourapp.com -> cname.vercel-dns.com.

MX Record -- This tells the internet where to deliver email for your domain. If you are using Google Workspace, the MX records point to Google's mail servers. If you are using any other email provider, they will give you MX records to add. Without these, nobody can email you at contact@yourapp.com.

TXT Record -- This is the Swiss army knife of DNS. TXT records hold text data that other services read for verification and security. The three TXT records you will use most are SPF, DKIM, and DMARC, which we will cover next.

SPF, DKIM, and DMARC: Why Your Emails Go to Spam

This is the part we learned the hard way. We set up our domain, configured email, sent a welcome message to our first user, and it went straight to their spam folder. Turns out, if you do not set up email authentication records, most email providers will treat your messages as suspicious.

SPF (Sender Policy Framework) tells receiving mail servers which servers are allowed to send email on behalf of your domain. It is a TXT record that looks something like: v=spf1 include:_spf.google.com include:sendgrid.net ~all. If you use Google Workspace for email and a service like Resend or SendGrid for transactional emails, both need to be in your SPF record. Miss one and those emails get flagged.

DKIM (DomainKeys Identified Mail) adds a digital signature to your outgoing emails. Your email provider generates a public/private key pair. The public key goes in a TXT record on your domain. When you send an email, the server signs it with the private key, and the receiving server checks it against the public key in your DNS. If they match, the email is legit.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together and tells receiving servers what to do if an email fails both checks. A basic DMARC record looks like: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourapp.com. Start with p=none if you want to monitor without blocking, then move to p=quarantine or p=reject once you are confident your legitimate emails are passing. We started with p=none for two weeks, reviewed the reports, and then switched to p=quarantine. This alone improved our deliverability significantly.

Setting Up Custom Domains for Your API

If you are building a SaaS product with a separate backend, you probably want api.yourapp.com instead of some-random-hash.up.railway.app. It looks more professional, it is easier for your frontend to call, and it means you can switch hosting providers without changing your client code.

The setup depends on your hosting provider, but the pattern is the same everywhere. Your provider gives you a target hostname or IP. You create a CNAME or A record pointing api.yourapp.com to that target. The provider detects the custom domain and provisions an SSL certificate. Most modern platforms like Railway, Render, and Fly handle the SSL part automatically.

One gotcha: if you are using Cloudflare as your DNS provider (which we recommend), make sure the proxy setting is correct. For most backend services, you want the orange cloud on (proxied) for your main domain but you might need it off (DNS only, gray cloud) for your API subdomain, depending on how the backend handles SSL termination. We spent hours debugging a 522 error that turned out to be Cloudflare proxying conflicting with Railway's SSL. Turning off the proxy for the API subdomain fixed it immediately.

Why Cloudflare Should Be Your First Stop

We have tried managing DNS at the registrar level and through Cloudflare. Cloudflare wins and it is not close. The free tier gives you DNS management, automatic SSL certificates, DDoS protection, and a CDN. For a small SaaS team, this is an incredible amount of infrastructure for zero dollars.

The setup is straightforward: you point your domain's nameservers to Cloudflare (they give you two), and then manage all your DNS records through their dashboard. Changes propagate fast, usually within a few minutes. And the dashboard is clean enough that you do not need a networking degree to use it.

One tip: once you move your nameservers to Cloudflare, any DNS records you had at your registrar stop working. So before you switch, screenshot or export everything from your registrar and re-create the records in Cloudflare first. We missed an MX record during migration once and did not realize our email was broken for six hours. Not fun.

SSL and Auto-Renewal: Set It and Forget It

SSL certificates used to be a paid, manual process. You would buy a certificate, install it on your server, and set a calendar reminder to renew it before it expired. If you forgot, your site would show a scary browser warning and your users would think you got hacked.

Those days are over. If you are using Cloudflare, they issue and auto-renew SSL certificates for all your domains. If you are deploying on Vercel, Railway, or similar platforms, they use Let's Encrypt to issue certificates automatically when you add a custom domain. You literally do nothing.

The only time SSL gets complicated is when you are running your own server or using a provider that does not handle it for you. In that case, certbot with Let's Encrypt is your friend. But honestly, in 2026, if your hosting platform does not auto-provision SSL, that is a sign to switch platforms.

The Mistakes That Will Cost You Hours

We have made most of the common DNS mistakes so you do not have to. Here are the ones that hurt the most.

Forgetting SPF records. Your transactional emails (password resets, welcome messages, receipts) go to spam. You do not notice for weeks because you test with your own email and Gmail is forgiving if you are logged into the same Google Workspace account. Your users, however, are on Outlook and Yahoo, and they never see your emails.

Using CNAME at the root. Technically, you should not use a CNAME record for the root domain (yourapp.com without www). Some DNS providers support it through a feature called CNAME flattening (Cloudflare does this), but others will silently break. Use an A record for the root domain or make sure your DNS provider supports flattening.

Not setting up DMARC. Even if your SPF and DKIM are perfect, without DMARC you are leaving the door open for spoofing. Plus, DMARC reports tell you if someone is trying to send email pretending to be your domain. It takes two minutes to set up and there is no reason not to.

Cloudflare proxy conflicts. When Cloudflare proxies your traffic (orange cloud), it terminates SSL at their edge and re-encrypts to your origin. Some backend platforms do not expect this and you get redirect loops or 522 errors. When in doubt, try DNS-only mode for your API subdomain first.

A Practical Checklist for Your Next Launch

Every time we launch a new product, we run through this checklist. It has saved us from repeating the same mistakes.

Register your domain. Move nameservers to Cloudflare. Add an A or CNAME record for the root domain pointing to your frontend host. Add a CNAME for www pointing to the same target. Add a CNAME for api pointing to your backend host. Add MX records for your email provider. Add a TXT record for SPF that includes all your email senders. Add DKIM TXT records from each email provider. Add a DMARC TXT record starting with p=none. Verify SSL is working on all subdomains. Send a test email to mail-tester.com and check your score. Aim for 10 out of 10.

It sounds like a lot, but once you have done it twice it takes about 20 minutes. And it means your users can find your site, your emails land in inboxes, and your API responds on a clean subdomain. That is the baseline. Everything else you build sits on top of this foundation.

Built by Obsidian Clad Labs -- a group of friends from Tennessee building software that protects people.

tags: saas, startup, webdev, beginners

Originally published at TeachShield Blog

Built by Obsidian Clad Labs — a group of friends from Tennessee building software that protects people.

How We Run 5 Live SaaS Products on $35/Month in Infrastructure

Obsidian Clad Labs — Mon, 06 Apr 2026 19:01:16 +0000

April 5, 2026 | 9 min read

When people hear that we run five live SaaS products -- each with its own frontend, backend API, database, and custom domain -- they assume we are spending hundreds of dollars a month on infrastructure. The reality is closer to $35. Sometimes less, depending on the month.

We are Obsidian Clad Labs, a small group of friends from Tennessee who build software products. We are bootstrapped, which means every dollar matters. We cannot afford to spend $50 per service just because that is the default starting plan. So we got creative with how we architect, deploy, and operate our products. Here is the full breakdown.

The Architecture Pattern

Every one of our products follows the same basic structure: a Next.js frontend deployed to a static hosting provider with a generous free tier, a Python FastAPI backend deployed to a container hosting platform, and a PostgreSQL database running alongside the backend. DNS and SSL are handled by a free CDN provider.

This pattern is not novel, but it is consistently cheap. The frontend hosting is free for all five products because static sites and serverless functions on modern hosting platforms cost effectively nothing at low traffic volumes. The backends and databases are where the costs live, and even those are modest when you are thoughtful about resource allocation.

Frontends: $0/Month

All five frontends run on a hosting platform's free tier. Each product gets its own project, its own custom domain, and automatic deployments on every git push. The free tier includes SSL certificates, edge caching, and serverless functions for any server-side rendering. For a product with a few hundred users, you will never exceed the free tier limits.

The key insight is that modern frontend hosting has become commoditized. The providers make their money from enterprise customers, and the free tier is genuinely sufficient for early-stage products. We have run five products for months without paying a cent for frontend hosting. When one product starts generating meaningful revenue, we will happily upgrade to a paid tier. Until then, free works.

Backends: ~$5-7 Per Service

Each backend runs as a container on a platform-as-a-service provider that charges based on actual resource usage rather than fixed plans. A typical FastAPI backend for one of our products uses about 256MB of RAM and minimal CPU when idle. The monthly cost works out to roughly $5 to $7 per service, depending on traffic.

The trick is keeping your services lean. We do not run background workers, cron jobs, or heavy processing on the same service as the API. If a product needs GPU processing (one of ours does, for image work), that runs on a separate serverless GPU platform that charges per-second of compute time rather than keeping an expensive GPU instance running 24/7.

Five backends at $5 to $7 each puts us at $25 to $35 for all backend compute. That includes the databases, because our hosting provider bundles PostgreSQL with the backend service at no additional cost for small databases.

DNS and SSL: $0/Month

All of our domains use a CDN provider's free plan for DNS management and SSL certificates. The free tier includes unlimited DNS queries, automatic SSL certificate provisioning and renewal, basic DDoS protection, and a global CDN. We manage all of our domains -- including subdomains for API endpoints -- through this single provider.

Domain registration itself costs about $10 to $15 per year per domain, but that is a one-time annual cost, not a monthly infrastructure expense. We have ten domains registered across all our products and the company site. That works out to less than $15 per month amortized, but we do not count it as infrastructure cost because it is a fixed business expense regardless of how the product is hosted.

Object Storage: $0-2/Month

Four of our five products use object storage for persistent file storage -- user uploads, generated PDFs, processed images. We use a provider that offers a generous free tier with 10GB of storage and no egress fees. At our current scale, we stay within the free tier for most products. One product occasionally crosses into paid territory during busy months, adding $1 to $2. For most small SaaS products, free-tier object storage will be more than sufficient for the first year.

Email: $0-3/Month

Transactional email (password resets, welcome emails, notifications) runs through a provider with a free tier that covers several thousand emails per month. At our current user count, we stay well within that limit across all five products. Business email (team inboxes, support addresses) runs through a workspace provider at about $6 per user per month, but that is a team cost rather than a per-product infrastructure cost.

The Principles Behind the Numbers

Keeping infrastructure costs this low is not about being cheap. It is about being disciplined. Here are the principles we follow.

Use free tiers aggressively. Most cloud providers offer free tiers that are more than sufficient for products with fewer than a thousand active users. Do not pay for a Pro plan until you have outgrown the free one. Read the limits carefully and design your architecture around them.

Share patterns, not infrastructure. Our five products share the same architectural pattern (Next.js + FastAPI + PostgreSQL), the same deployment workflow (git push triggers auto-deploy), and the same monitoring approach. But they do not share databases, servers, or accounts. Each product is independently deployable and independently billable. If one product takes off, its costs scale independently.

Only pay for what you need. Usage-based pricing is your friend as a bootstrapped founder. Fixed monthly plans that charge $20 to $50 per service regardless of usage will eat you alive when you are running multiple products. Choose providers that charge based on actual compute, storage, and bandwidth consumed.

Do not over-provision. A backend serving a handful of users does not need 1GB of RAM, a dedicated database server, or a load balancer. Start with the minimum viable resources and scale up only when monitoring tells you that you need to. We have products running happily on 256MB containers that handle their current traffic without breaking a sweat.

When This Approach Stops Working

To be clear, this setup works because we are early-stage. We have dozens of users, not thousands. When a product starts generating meaningful revenue and attracting real traffic, infrastructure costs will go up. Databases will need more storage. Backends will need more memory. We will probably want dedicated monitoring, logging, and alerting services.

But that is a good problem to have. The goal is not to run five products on $35 forever. The goal is to survive long enough for one of those products to generate enough revenue to justify proper infrastructure spending. Until then, every dollar we do not spend on servers is a dollar we can spend on reaching the next customer.

The Full Monthly Breakdown

Here is the honest breakdown of what we pay each month to keep five live SaaS products running with custom domains, SSL, databases, APIs, and transactional email:

Frontend hosting for five products: $0. Backend compute for five services: $25 to $35. Database hosting (bundled): $0. DNS and SSL: $0. Object storage: $0 to $2. Transactional email: $0 to $3. Total: roughly $25 to $40 per month, averaging $35 in a typical month.

That is not a typo. Five live products with full stacks for the price of a few cups of coffee. If you are a solo founder or small team thinking about launching multiple products, do not let infrastructure costs scare you. It has never been cheaper to build.

Built by Obsidian Clad Labs -- a group of friends from Tennessee building software that protects people.

tags: saas, startup, webdev, beginners

Originally published at TeachShield Blog

Built by Obsidian Clad Labs — a group of friends from Tennessee building software that protects people.

Our Email Provider Banned Us Overnight -- Here's What We Learned

Obsidian Clad Labs — Mon, 06 Apr 2026 19:01:09 +0000

April 6, 2026 | 8 min read

We woke up on a Tuesday morning to find that every single email our products sent -- password resets, welcome messages, subscription confirmations, grading notifications -- was bouncing. Not some of them. All of them. Our email provider had permanently disabled our account overnight, with no warning and no appeal process. Just a single-line notification: "Your account has been suspended due to policy violations."

We are a small group of friends from Tennessee building SaaS products under our company, Obsidian Clad Labs. We run five live products, and every one of them depends on transactional email to function. This was not an inconvenience. It was a full-blown emergency. Here is what happened, what we did wrong, and what we learned so you do not make the same mistakes.

What Actually Happened

The root cause was embarrassingly simple. One of our team members had been doing outreach -- cold emails to potential users we thought might benefit from one of our products. The email list was not validated. Many addresses were outdated, misspelled, or simply did not exist. The result was a bounce rate above 15%, which is catastrophically high by any email provider's standards.

Most email providers have a hard limit around 5% bounce rate. Go above that and you trigger automated fraud detection systems. Go way above that, as we did, and your account gets flagged as a spam source and terminated. The provider does not care that your transactional emails are legitimate. They care about protecting their sending reputation and their other customers. From their perspective, they made the right call.

The problem was that we were sending marketing outreach through the same account we used for transactional email. When the outreach emails bounced, the entire account got flagged, and our perfectly legitimate password resets and welcome emails went down with it.

The Emergency Migration

We had about three hours between discovering the problem and our first users reporting that they could not reset their passwords. The fix was straightforward but stressful: sign up with a new email provider, verify our domains, update the API keys across all five backends, test delivery, and deploy.

Because we had built our email sending through a thin abstraction layer rather than calling the provider's API directly everywhere, the actual code changes were minimal. We updated the API key and endpoint in our environment variables, verified that the new provider accepted our domain's DNS records (SPF, DKIM, and DMARC were already properly configured from our original setup), and redeployed each backend service.

The entire migration took about four hours from discovery to full restoration. It could have been much worse. If we had hardcoded our email provider's SDK throughout the codebase instead of using a wrapper, we would have been rewriting email logic across five separate codebases under pressure.

Lesson 1: Always Validate Email Addresses Before Sending

This is the most basic rule we broke. Before sending any batch of emails, especially cold outreach, you need to verify that the addresses actually exist. There are email validation services that check MX records, detect disposable addresses, and identify addresses that are likely to bounce. They cost a few dollars per thousand addresses.

We now validate every email address before it enters any sending queue. For user-submitted emails (signups, contact forms), we verify the domain has valid MX records before accepting it. For outreach lists, we run the entire list through a validation service and remove anything that does not pass. A five-minute validation step would have prevented our entire crisis.

Lesson 2: Separate Transactional from Marketing Email

This was our biggest architectural mistake. Transactional emails (password resets, welcome messages, receipt confirmations) are critical infrastructure. They have open rates above 80% and near-zero bounce rates because they are sent to addresses that just performed an action on your site. Marketing emails (newsletters, outreach, promotional campaigns) have inherently higher bounce rates, lower engagement, and carry reputation risk.

These two types of email should never share the same sending account, the same domain, or ideally even the same provider. We now use one provider exclusively for transactional email and handle any marketing or outreach through a completely separate service with a different subdomain. If outreach goes wrong again, our transactional email keeps working.

Lesson 3: Implement Rate Limiting and Monitoring

We had no monitoring on our email sending. No alerts for bounce rate spikes. No daily limits on outbound volume. No dashboards showing delivery health. We were flying blind, and we did not even know it until the account was already dead.

Now we track bounce rate, delivery rate, and complaint rate in real time. We have alerts that fire if the bounce rate exceeds 2% on any given day. We have hard daily sending limits that cannot be overridden without a manual review. These guardrails exist specifically to prevent a repeat of what happened. If something starts going wrong, we know within hours, not after the provider has already pulled the plug.

Lesson 4: Have a Migration Plan Ready

The reason we survived this incident in four hours instead of four days is that we had (somewhat accidentally) built our email integration in a way that made switching providers easy. The API key and endpoint were environment variables. The email sending logic was behind an abstraction. Our DNS records were already configured correctly with SPF, DKIM, and DMARC.

We now treat email provider migration as a documented runbook. We know exactly which environment variables to update, which DNS records to verify, and which test emails to send to confirm delivery. We even have a backup provider account pre-configured and ready to activate. If our current provider goes down or bans us again tomorrow, we can switch in under an hour.

Lesson 5: Your Email Reputation Is Fragile

Email deliverability is not something most developers think about until it breaks. But your sending reputation -- which is tied to your domain, your IP address, and your provider account -- is one of the most fragile assets in your infrastructure. A single bad batch of emails can destroy months of built-up reputation in minutes.

Treat your email sending reputation the way you treat your production database: with extreme caution, proper monitoring, and a healthy fear of doing anything that might corrupt it. Never send emails to unvalidated addresses. Never mix marketing with transactional. Never skip the monitoring. Your users depend on receiving your emails, even if they do not think about it until they cannot.

The Silver Lining

Losing our email provider was one of the most stressful days we have had building this company. But it forced us to build better infrastructure than we had before. Our email setup is now more resilient, better monitored, and properly separated by purpose. We have a migration plan that we have actually tested. We validate every address before sending.

If you are building a SaaS product and you have not thought about what happens when your email provider disappears overnight, think about it now. Set up the monitoring. Separate your sending accounts. Validate your addresses. Build the abstraction layer. Do it while it is a calm Tuesday afternoon, not while your users are locked out of their accounts.

Built by Obsidian Clad Labs -- a group of friends from Tennessee building software that protects people.

tags: saas, startup, webdev, beginners

Originally published at TeachShield Blog

Built by Obsidian Clad Labs — a group of friends from Tennessee building software that protects people.

AI Contract Review: How ClauseShield Analyzes Contracts in 60 Seconds

Obsidian Clad Labs — Fri, 06 Mar 2026 13:31:24 +0000

There are roughly 59 million freelancers in the United States alone. Most of them sign contracts regularly. Almost none of them have those contracts reviewed by a lawyer.

The reason is simple: cost. A contract attorney charges anywhere from $200 to $500 per hour. A basic contract review runs $300 to $1,000. When your project fee is $3,000, spending $500 on legal review eats a significant portion of your profit. So freelancers skip the review, sign what the client sends, and hope for the best.

That gamble works until it does not. A missing liability cap, an overbroad NDA, or a one-sided termination clause can cost you far more than a legal review ever would. The problem was never that freelancers did not want their contracts reviewed -- it was that they could not afford it.

ClauseShield changes that equation entirely.

How ClauseShield Works: Upload to Analysis in Under 60 Seconds

The process is deliberately simple. There are three steps, and the entire workflow takes less than a minute.

Step 1: Upload Your Contract

Drag and drop your contract file or paste the text directly. ClauseShield accepts PDF, DOCX, and plain text formats. There is no account setup required for your first analysis -- you can test the tool before committing.

Step 2: AI Analysis with Legal-BERT

This is where the technology does the heavy lifting. ClauseShield's AI engine processes your contract through multiple analysis layers:

Clause Classification -- The AI reads every sentence of your contract and classifies each clause into one of eight legal categories:

Payment -- Invoicing terms, payment schedules, late fees
Termination -- Cancellation rights, notice periods, kill fees
IP Ownership -- Who owns the work product and when
Liability -- Damage caps, indemnification, warranties
NDA/Confidentiality -- Scope, duration, exclusions
Non-Compete -- Restrictions on future work
Kill Fee -- Cancellation compensation
Other -- General terms, governing law, dispute resolution

Risk Scoring -- Each clause receives a risk score from 0 to 100, where 0 means no risk and 100 means maximum risk to you as the freelancer. The scores are based on over 70 rule-based risk patterns that identify specific language patterns associated with unfavorable terms.

For example, a liability clause with no cap scores high risk. A payment clause with Net 60 terms scores moderate risk. A termination clause with a 30-day notice period and kill fee scores low risk.

Overall Contract Score -- The individual clause scores roll up into a single contract-level risk score, giving you an at-a-glance assessment of how safe the contract is to sign.

Step 3: Plain-English Results and Redline Export

ClauseShield does not just flag problems -- it explains them. Every risky clause comes with:

A plain-English explanation of what the clause means
Why it is risky for you specifically as a freelancer
What a fairer version of the clause would look like
Suggested alternative language you can propose to the client

When you are ready to negotiate, ClauseShield generates a redline document -- a version of the contract with proposed changes tracked, ready to send back to the client. Export to Word, PDF, or plain text, depending on what works best for your workflow.

What Makes ClauseShield Different

There are other contract review tools on the market. Here is why ClauseShield was built specifically for freelancers and why it outperforms generic alternatives.

Trained on 40,000 Real Legal Clauses

ClauseShield's AI is not a generic language model guessing at legal meaning. It is built on Legal-BERT, a transformer model specifically pre-trained on legal text, then fine-tuned on a curated dataset of 40,000 balanced contract clauses drawn from five major legal datasets:

LEDGAR -- SEC contract provisions
CUAD -- Contract Understanding Atticus Dataset
ContractNLI -- Contract natural language inference
MAUD -- Merger agreement understanding
UnfairToS -- Unfair terms of service

This training data ensures the model understands legal language at a level that general-purpose AI tools cannot match.

F1 Score of 0.9764

In machine learning, the F1 score measures how accurately a model classifies data. ClauseShield achieves a macro F1 score of 0.9764 across all eight clause categories. In practical terms, this means the AI correctly identifies and classifies clauses with near-human accuracy.

For context, an F1 score above 0.95 is considered excellent in any classification task. ClauseShield's 0.9764 means fewer than 3 in 100 clauses are misclassified -- and even those edge cases are flagged for manual review.

70+ Rule-Based Risk Patterns

Beyond the AI classifier, ClauseShield applies over 70 hand-crafted risk detection rules that catch specific red flags:

Unlimited liability language
Perpetual NDA durations
Missing payment timelines
One-sided termination rights
IP assignment without payment conditions
Non-compete clauses disguised as NDAs
"Work made for hire" language without fair compensation
Indemnification without caps

These rules work alongside the AI model to catch issues that statistical classification alone might miss.

Sub-Second Analysis

ClauseShield processes contracts in under one second of compute time. The entire workflow -- upload, classification, risk scoring, explanation generation -- completes before you can finish reading this sentence. No waiting for batch processing, no "check back in 24 hours."

Pricing: Built for Freelancer Budgets

ClauseShield offers three tiers designed to match how freelancers actually work:

Free -- 3 contract analyses per month. No credit card required. Ideal for freelancers who sign a few contracts per quarter and want basic protection.
Pro ($15/month) -- 15 contract analyses per month, plus full redline export. For active freelancers managing multiple clients.
Premium ($29/month) -- Unlimited contract analyses, priority processing, and full redline export. For agencies, prolific freelancers, and anyone who signs contracts weekly.

Compare that to a single lawyer review at $300-$500. The Pro plan pays for itself the first time you catch a risky clause that would have cost you more than $15 to resolve.

A Real Use Case: Catching What You Would Miss

Here is a walkthrough of what ClauseShield catches in a typical freelance contract.

A web developer receives a 12-page contract from a new client. She uploads it to ClauseShield. In under a minute, the analysis returns:

Overall Risk Score: 72/100 (High Risk)

The AI flags four issues:

Liability (Risk: 91/100) -- The contract contains no liability cap. The developer is exposed to unlimited damages. ClauseShield suggests adding a cap at 1x total fees paid.
Termination (Risk: 78/100) -- The client can terminate immediately for convenience with no notice period and no kill fee. The developer has no equivalent right. ClauseShield suggests a mutual 30-day notice period with payment for all completed work.
NDA (Risk: 65/100) -- The confidentiality clause is perpetual and defines "confidential information" as "all information disclosed in any form." Standard exclusions are missing. ClauseShield suggests a 2-year duration and standard carve-outs.
Payment (Risk: 58/100) -- Payment terms are Net 60 with no late payment penalties. ClauseShield suggests Net 30 with 1.5% monthly interest on overdue invoices.

The developer exports the redline, sends it to the client, and negotiates three of the four changes. The entire process -- from upload to sending the redline -- takes less than 15 minutes.

Without ClauseShield, she would have signed the contract as-is. The liability clause alone could have exposed her to losses far exceeding the project fee.

Who ClauseShield Is Built For

ClauseShield is designed for anyone who signs freelance contracts and does not have a lawyer on retainer:

Freelance developers and designers reviewing client service agreements
Writers and content creators signing publishing and work-for-hire contracts
Consultants entering into advisory and service engagements
Agencies processing multiple client contracts per month
New freelancers who have never reviewed a contract and do not know what to look for

If you sign contracts as part of your work and you are not currently having them reviewed, ClauseShield exists to close that gap.

Try ClauseShield Today

Every unsigned contract is a chance to protect yourself -- or a chance to miss something that costs you later. ClauseShield gives you the analysis a contract lawyer would provide, in the time it takes to pour a cup of coffee, at a price that makes sense for freelancer budgets.

Your first three analyses are free. No credit card. No commitment.

Start analyzing your contracts at clauseshield.app and find out what is hiding in the fine print.

Termination for Convenience: What It Really Means for Your Income

Obsidian Clad Labs — Fri, 06 Mar 2026 13:31:18 +0000

You are three weeks into a six-week project. The work is going well. Then you get an email: "We've decided to go in a different direction. Per Section 12 of our agreement, we are terminating this contract effective immediately."

You check Section 12. It says the client can cancel the contract at any time, for any reason, with no notice and no obligation beyond paying for hours already logged. The deposit you received covered week one. Weeks two and three? You invoiced but have not been paid yet. And the three weeks of income you planned on? Gone.

This is termination for convenience in action, and it is one of the most one-sided clauses in freelance contracts.

Termination for Cause vs. Termination for Convenience

These are two fundamentally different rights, and your contract probably includes both.

Termination for cause allows either party to end the contract when the other party has breached the agreement. You missed a deadline, delivered substandard work, or violated a contract term. Conversely, you can terminate for cause if the client fails to pay you, changes the scope without agreement, or violates their obligations.

Termination for cause is fair. It protects both sides from a dysfunctional engagement.

Termination for convenience allows one or both parties to end the contract for any reason or no reason at all. There does not need to be a breach, a dispute, or any justification. The party simply decides they no longer want to continue.

The problem is not that termination for convenience exists -- it is that many contracts give only the client this right, with no protections for the freelancer.

Notice Period Requirements

The single most important protection in a termination-for-convenience clause is the notice period. This is the amount of time the terminating party must give before the termination takes effect.

No notice (immediate termination) -- The worst case. The client can pull the plug today and you are done today. You have no time to adjust, line up new work, or wind down gracefully.
7 days -- Minimal, but better than nothing. Gives you a week to wrap up and start looking for replacement income.
14 days -- Reasonable for short-term projects. Two weeks provides a meaningful buffer.
30 days -- The gold standard. A full month of notice gives you time to find new work, complete in-progress deliverables, and transition smoothly.

What to negotiate: Push for a minimum 14-day notice period for projects under three months, and 30 days for longer engagements. During the notice period, the contract should remain fully in effect -- meaning the client still pays you for work performed.

"Either party may terminate this Agreement for convenience upon thirty (30) days' written notice to the other party. During the notice period, all terms of this Agreement shall remain in full force and effect, and Client shall pay Contractor for all services rendered through the effective date of termination."

Payment for Work Completed

When a contract terminates, you must be paid for all work completed up to the termination date. This sounds obvious, but you would be surprised how many contracts are ambiguous on this point.

Watch for language that conditions final payment on "client satisfaction" or "acceptance of deliverables." If the client terminates for convenience before reviewing your latest deliverables, they could argue they never "accepted" the work and therefore owe nothing.

Strong protective language states:

"Upon termination for any reason, Client shall pay Contractor for all services performed and expenses incurred through the effective date of termination within fifteen (15) days of said date. Payment shall not be contingent upon Client's review, approval, or acceptance of deliverables completed prior to termination."

Kill Fees: Compensation for the Cancellation Itself

A kill fee is a fixed payment the client owes you simply for exercising their termination-for-convenience right. It compensates you for the opportunity cost of having reserved your time and turned away other work.

Kill fees are common in creative industries -- journalism, photography, video production, and design. They typically range from 25% to 50% of the remaining contract value.

Example: You have a $12,000 contract. The client terminates after $4,000 worth of work is completed, leaving $8,000 on the table. With a 25% kill fee, the client owes you the $4,000 for completed work plus $2,000 (25% of the remaining $8,000) as a cancellation fee. Your total payout is $6,000 instead of $4,000.

Kill fees are not standard in every industry, but they are always worth proposing. The worst the client can say is no.

"In the event Client terminates this Agreement for convenience, Client shall pay Contractor a termination fee equal to twenty-five percent (25%) of the remaining unpaid balance of the Agreement, in addition to all fees owed for services performed through the date of termination."

Wind-Down Obligations

Termination does not mean everything stops instantly. There are practical matters to address:

Transition of work product -- Who owns the partially completed deliverables? Can you hand them off in their current state, or are you expected to bring them to a logical stopping point?
Knowledge transfer -- If you are the only person who understands the work, the client may need documentation or a handoff meeting. Your contract should specify whether this is included in the termination or billed separately.
Return of materials -- Client files, access credentials, proprietary assets. Both sides should have clear obligations to return the other party's materials within a defined timeframe.
Final invoicing -- Specify a deadline for submitting your final invoice and a deadline for the client to pay it. Do not leave this open-ended.

What Happens to Deliverables on Termination

This is where many freelancers get burned. You have completed three of five deliverables. The client terminates. Do they own those three deliverables?

The answer depends entirely on your contract's intellectual property clause and how it interacts with the termination clause. There are two common approaches:

IP transfers on payment: You retain ownership of all work product until the client pays for it. If they terminate and pay for three deliverables, they own three deliverables. If they do not pay, they own nothing.

IP transfers on creation: The client owns all work product the moment it is created, regardless of payment. This is worse for you because the client could terminate, refuse to pay, and still argue they own the work.

Always tie IP transfer to payment. This gives you leverage in any termination dispute and ensures you are never giving away work for free.

"All intellectual property rights in the deliverables shall transfer to Client upon receipt of full payment for each respective deliverable. In the event of termination, IP rights shall transfer only for deliverables that have been paid for in full."

Protect Yourself Before Signing with ClauseShield

Termination clauses are often written in dense legalese and buried deep in the contract. A missing notice period, an absent kill fee, or an IP clause that transfers ownership before payment can cost you thousands of dollars if the engagement ends early.

ClauseShield scans your contract and flags one-sided termination language instantly. Our AI identifies missing notice periods, absent kill fees, payment-on-termination gaps, and IP transfer risks -- then explains what each clause means and how to negotiate better terms.

Try ClauseShield free at clauseshield.app and make sure your next contract has a safety net built in.