DEV Community: Subhendu Das

AI content generation: the automated blog draft feature

Subhendu Das — Sun, 18 Oct 2026 17:15:48 +0000

Overview

DoAide Pulse gives indie developers a way to turn project documentation into publishable content without writing a line of copy. The Create from documents feature is the core of that promise. It lets a developer upload a Markdown or plain‑text file, optionally supply an LLM API key, and then queues a generation job that produces a ready‑to‑publish draft.

Problem

Writing marketing copy for a side project is a recurring pain point. A developer spends hours turning a README into a blog post, then re‑writes for social. The process is manual, error‑prone, and hard to schedule. On top of that, many developers use a custom LLM or a hosted model; the platform must respect that choice instead of forcing a single provider.

How It Works

The feature is built on a stack that mirrors the rest of DoAide Pulse:

FastAPI endpoint – Accepts a file upload and an optional llm_key field. The request is authenticated via a JWT issued by the dashboard.
SQLAlchemy model – Stores the draft in a drafts table with columns for project_id, source_path, llm_provider, llm_key_hash, and status.
Celery worker – Picks up the draft, loads the LLM key from the database, and streams a prompt that instructs the model to convert the source document into a blog‑ready article.
Redis queue – Ensures the generation job is processed asynchronously, freeing the API from long‑running calls.
Post‑processing – After generation, the worker runs a quick lint pass to fix Markdown syntax, adds front‑matter tags, and pushes the result to a content calendar entry.
Dev.to API – When the user approves the draft, a FastAPI route triggers an authenticated call to the Dev.to endpoint, posting the article with the correct tags and scheduled time.

Code Snippet: FastAPI Route

from fastapi import APIRouter, File, Form, UploadFile, Depends
from sqlalchemy.orm import Session
from app.db import get_db
from app.models import Draft

router = APIRouter()

@router.post("/drafts/", status_code=202)
async def create_draft(
    file: UploadFile = File(...),
    llm_key: str = Form(None),
    db: Session = Depends(get_db),
    user: User = Depends(get_current_user),
):
    content = await file.read()
    draft = Draft(
        project_id=user.project_id,
        source_path=file.filename,
        llm_provider="custom",
        llm_key_hash=hash_key(llm_key),
        status="queued",
    )
    db.add(draft)
    db.commit()
    celery_app.send_task("tasks.generate_draft", args=[draft.id])
    return {"detail": "Draft queued for generation"}

This is where marketing automation pays off in practice.

Code Snippet: Celery Task

from celery import shared_task
from app.db import get_db
from app.models import Draft
from app.llm import generate_from_docs

@shared_task
def generate_draft(draft_id: int):
    db = get_db()
    draft = db.query(Draft).filter(Draft.id == draft_id).one()
    llm_key = decrypt_key(draft.llm_key_hash)
    result = generate_from_docs(draft.source_path, llm_key)
    draft.generated_content = result
    draft.status = "ready"
    db.commit()

Getting marketing automation right early saves rework later.

Using It

Upload – From the dashboard’s Drafts tab, click Create from documents, choose a file, and optionally paste your LLM API key.
Queue – The UI shows a spinner and a status badge that updates from queued → processing → ready.
Review – Once ready, the draft appears in the Content Calendar with a preview. You can edit the Markdown, adjust tags, or change the scheduled publish time.
Approve – Hit Publish; the system calls the Dev.to API, logs the article URL, and updates the dashboard with the live link.

The entire flow takes a few seconds for the API call, a few minutes for generation (depending on the LLM), and then instant posting. No manual copy‑paste or external tooling is required. Good marketing automation keeps the rest of the workflow predictable.

Technical Details

FastAPI handles HTTP and WebSocket endpoints, providing low‑latency routing.
SQLAlchemy maps the drafts table to a Python class, enabling migrations via Alembic.
Celery + Redis decouple the long‑running generation from the request‑response cycle.
React + Vite + Tailwind CSS render the dashboard; the Drafts component fetches status via a polling hook.
PostgreSQL stores draft metadata and content; migrations include a CHECK constraint to ensure status values are valid.
Dev.to API integration uses the devto Python package (or raw requests) with OAuth scopes for publishing.

The commit log shows recent fixes that directly benefit this feature: automatic SEO preflight fixes, dashboard bug patches, and analytics pipeline health checks. These improvements mean that every generated draft is already SEO‑ready and that the UI remains stable even under load. Treat marketing automation as a habit rather than a one-off task.

Conclusion

By turning raw documentation into polished blog posts, the Create from documents feature removes the friction that typically deters indie developers from marketing their work. It leverages the same core stack that powers DoAide Pulse’s scheduling, publishing, and analytics, ensuring a consistent developer experience across the platform.

Audit Defense Toolkit: 409A Valuation Compliance

Subhendu Das — Sat, 10 Oct 2026 15:22:41 +0000

The Problem: Uncertainty in 409A Compliance

Startup founders and finance teams face a high‑stakes challenge every time they issue equity: the 409A valuation must be defensible under IRC 409A. A single misstep can trigger an IRS audit, leading to back‑dated taxes, penalties, and a loss of trust among investors. Traditional approaches rely on spreadsheets, manual documentation, and external consultants—processes that are time‑consuming, error‑prone, and difficult to audit.

The core pain points are

Lack of a clear audit trail – each valuation step must be traceable.
Fragmented evidence – data from multiple sources (financial statements, market comps, internal models) must be collated.
Compliance fatigue – keeping up with evolving audit standards and documentation requirements is exhausting.

Founders often ask: How can I prove that my valuation is fair market value and meets 409A compliance without hiring a firm for months? The answer lies in an integrated, AI‑driven audit defense toolkit.

The Solution: Audit Defense Toolkit

N409’s audit defense toolkit is designed to answer that question directly. It bundles the evidence, documentation, and audit‑ready reports needed to defend a valuation against an IRS audit. The toolkit automatically pulls data from the valuation model, generates a PDF summary, and logs every change in an immutable audit trail. By centralizing this information, founders can present a single, coherent narrative to auditors and regulators.

Key capabilities include:

Automated evidence collection – the platform pulls model inputs, market data, and internal financials into a structured format.
Versioned audit trail – every change to a valuation is timestamped and stored, ensuring that the lineage of the fair market value is transparent.
Compliance checklists – built‑in prompts confirm that all IRC 409A requirements are met before finalizing a report.
Ready‑to‑submit PDFs – the toolkit produces a PDF that includes all supporting documentation, ready for upload to IRS portals or for sharing with auditors.

These features reduce the risk of a costly audit and give founders confidence that their equity compensation strategy is compliant.

How It Works

The toolkit is built on N409’s core stack: a NestJS/TypeScript backend, a React/Vite front‑end, and a Python data‑science layer that drives the AI analysis. When a valuation is generated, the backend triggers a series of micro‑services:

Data ingestion – the Python layer pulls in market comps and internal financials, normalizes the data, and feeds it into the valuation engine.
Evidence packaging – a dedicated micro‑service compiles the inputs, the AI‑derived valuation, and the audit checklists into a single JSON bundle.
PDF rendering – using a headless browser, the service renders a PDF that includes the plain‑English summary, the raw data tables, and the audit trail.
Audit trail logging – every step is logged in PostgreSQL with a unique transaction ID, and a Redis cache is used to provide real‑time status updates to the client portal.

The audit defense toolkit is tightly integrated with the client portal, so founders can view the audit status in real time and download the PDF with a single click.

User Experience

During onboarding, a founder is guided through a wizard that asks for the necessary data sources—Xero, QuickBooks, or a spreadsheet. The audit defense toolkit automatically validates the inputs against the IRC 409A checklist. If any field is missing, the wizard highlights the issue and provides a link to the relevant documentation.

Once the valuation is complete, the founder receives an email with a link to the audit‑ready PDF. The portal displays a progress bar that updates in real time as the PDF is rendered and the audit trail is finalized. If the founder wants to review the evidence, they can click through to see the raw data tables, the AI rationale, and the version history.

Because the toolkit is fully automated, a CFO can generate a new valuation in minutes instead of weeks, and the audit trail is automatically preserved for future reference.

Technical Backbone

Security and observability are critical for audit readiness. Recent commits to the N409 repository demonstrate a focus on these areas:

Observability updates – silent OAuth errors and PDF render timings are now logged, ensuring that any failure is traceable.
Dependency patching – CVEs are fixed and a floor‑version regression test prevents accidental upgrades that could break the audit trail.
Rate limiting – a defensive limit on per‑valuation list queries prevents abuse and protects the integrity of the audit data.
Deployment hardening – the CI pipeline now includes firewall rules and Docker caching to reduce attack surface.

These improvements mean that the audit defense toolkit can be trusted to maintain the integrity of the valuation evidence.

Real‑World Impact

With the audit defense toolkit, founders no longer need to juggle multiple spreadsheets, external consultants, and manual documentation. The platform’s single, audit‑ready PDF consolidates all the evidence required to satisfy an IRS audit. This reduces the risk of penalties, speeds up the equity issuance process, and frees finance teams to focus on strategy rather than compliance paperwork.

In short, the audit defense toolkit transforms the 409A valuation from a compliance burden into a confidence‑building asset for any startup that relies on equity compensation.

Login-Free 409A Valuation Tools Remove Friction for Founders

Subhendu Das — Sat, 10 Oct 2026 09:23:49 +0000

The Problem: Account Fatigue Before You Even Start

Startup founders evaluating 409A valuation providers often hit a wall before seeing any value: create an account, verify email, fill in company details — all before accessing a single calculator or cost estimate. For a team racing toward a board meeting or option grant deadline, that friction costs time and momentum.

The Change: Tools First, Signup Optional

N409 recently removed the login gate from its core 409A tools. The commit reads: "feat: make 409A tools login-free with optional signup prompt." Now, founders and finance leads can open the platform and immediately use the valuation timeline, readiness checker, and cost comparison tools — no account required. A signup prompt appears only when a user wants to save results or continue into the full valuation workflow.

How It Works

The implementation keeps the tooling intact while decoupling identity from exploration. The valuation timeline shows the typical steps and duration from data collection to final report. The readiness checker evaluates whether a company's financials, cap table, and documentation are prepared for a defensible 409A valuation. The cost comparison tool benchmarks N409's automated approach against traditional firm pricing. Each tool runs client-side or via anonymous API calls, storing nothing until the user chooses to persist a session.

When a user decides to proceed — perhaps after seeing a cost estimate or confirming readiness — the optional signup prompt appears. It captures the minimum needed to spin up a workspace: email, company name, and a password. From there, the platform connects to accounting integrations (Xero, QuickBooks, FreshBooks, NetSuite, Sage, Wave) and begins the AI-driven analysis across 13 valuation methodologies.

What It Looks Like to Use

A founder lands on the tools page from a search for "409A valuation cost" or "startup valuation timeline." They see three interactive cards: Timeline, Readiness, Cost Comparison. Clicking "Check Readiness" opens a short questionnaire about revenue stage, last funding round, cap table complexity, and financial statement availability. Results appear instantly — a score with specific gaps flagged (e.g., "missing audited financials," "cap table not exported"). No modal interrupts. No email capture.

If the score looks good, a subtle banner suggests: "Ready to start your 409A? Create a free workspace to save this assessment and begin data import." The founder can dismiss it, share the result via a generated link (another new feature: viral sharing with WhatsApp and deadline widgets), or sign up. The choice stays with the user.

Why It Matters for 409A Compliance

IRC 409A requires a reasonable valuation method applied consistently. The readiness checker helps teams self-assess whether they have the inputs — fair market value analysis, comparable transactions, discount for lack of marketability — before engaging a provider. The cost comparison clarifies what "reasonable" costs in an automated context versus a traditional engagement. By exposing these tools without a gate, N409 lets founders do the upfront homework that makes the actual valuation faster and more defensible.

Built on the Existing Stack

The login-free layer sits on N409's NestJS/TypeScript backend with PostgreSQL and Redis, using OpenRouter AI for the analytical heavy lifting. The React/Vite frontend handles anonymous sessions via short-lived tokens. When a user converts, the session upgrades to a full account with access to the client portal, audit defense toolkit, and scenario analysis (bull/base/bear/custom) — features that remain behind authentication because they involve sensitive cap table data and report generation.

The Trade-Off

Removing the gate increases top-of-funnel traffic and reduces bounce, but it also means anonymous usage analytics replace identified user journeys for the first interaction. The team mitigates this with the optional signup prompt placed at the moment of highest intent: after a tool delivers a concrete result. The commit history shows accompanying fixes for mobile landing UX and theme tokens, suggesting the rollout included a polish pass on the unauthenticated experience.

For a founder comparing 409A valuation options at 10 p.m. before a board deck, that moment — tools ready, no forms — is the difference between evaluating a platform and closing the tab.

GoSumo Makes WhatsApp Optional with Native wa.me Links

Subhendu Das — Fri, 09 Oct 2026 13:30:01 +0000

The Problem: WhatsApp Business API Friction for Small Teams

Indian SMBs running lean operations often hit a wall when trying to add WhatsApp to their client management stack. The official WhatsApp Business API requires Meta Business verification, template approval workflows, and ongoing infrastructure costs — overhead that many small teams can't justify just to reply to customer inquiries. For businesses already juggling Instagram DMs, SMS, email, and web chat, adding another complex integration slows down the very conversations they're trying to accelerate.

The Shift: From Managed API to Device-Native Links

GoSumo's latest update removes the WhatsApp Business API as a required dependency. Instead of routing messages through Meta's cloud infrastructure, the platform now generates standard wa.me links — the same universal links that open a WhatsApp chat directly on the user's phone or desktop app. The change appears in the settings panel where WhatsApp Business API is now marked optional, and the underlying integration has been swapped for these native deep links.

Technically, this means GoSumo no longer needs to maintain a Business API client, handle webhook verification, or manage template namespaces. When an operator clicks a customer's WhatsApp contact in the unified inbox, the browser opens wa.me/<phone-number>?text=<prefilled-message>, launching the native WhatsApp client with context preserved. The conversation continues on the device where the business already manages their personal and professional chats.

What This Looks Like in Practice

For an operations team handling omnichannel support, the workflow changes subtly but meaningfully:

Unified inbox remains intact — WhatsApp conversations still appear alongside Instagram DMs, SMS, email, and web chat in the single AI-driven interface.
No template constraints — Operators can type free-form replies without pre-approved message templates, since they're sending from their own WhatsApp account.
Zero API maintenance — No webhook endpoints to monitor, no rate-limit handling, no Meta policy changes to track.
Device continuity — Conversations sync naturally across the business owner's phone, WhatsApp Web, and desktop app — the same surfaces they already use.

The trade-off is clear: you lose automated session management, chatbot handoffs, and message analytics that the Business API provides. But for Indian SMBs where the owner or a small team personally handles most conversations, the simplicity often outweighs the automation. The AI customer service layer still applies to other channels — Instagram DM automation, email triage, web chat routing — while WhatsApp becomes a direct, human-operated line.

Why This Matters for the Target User

The commit message "replace Meta WhatsApp API with device-native wa.me links" signals a deliberate product decision: optimize for adoption speed over enterprise feature parity. An Indian SMB owner can now connect WhatsApp in seconds — no Business Manager account, no verification wait, no developer setup. They paste their number, save, and the channel appears in their client management dashboard.

This aligns with the platform's core promise: a single interface for customer conversations across WhatsApp, Instagram, SMS, web chat, and email, without forcing every channel through the same heavy infrastructure. The wa.me approach keeps WhatsApp lightweight while the AI-driven interface handles routing, tagging, and context enrichment on the channels that support it natively.

For teams that later need Business API features — broadcast messaging, chatbot flows, green-badge verification — the option remains in settings. But it's no longer the price of entry.

Marketing Automation: AI‑Generated SEO Fields in DoAide Pulse

Subhendu Das — Fri, 09 Oct 2026 11:31:47 +0000

Problem

For indie developers and small teams, publishing a blog post or newsletter often means juggling several repetitive tasks: writing a headline, crafting a meta description, and ensuring the content meets SEO best practices. These steps are usually done manually in the UI, which slows down the content pipeline and introduces human error. When a developer wants to ship a side project, the marketing automation stack should handle these details automatically, freeing time for coding.

Solution

DoAide Pulse introduces an AI‑powered feature that auto‑generates SEO titles and descriptions. Instead of clicking a “Generate” button that runs a basic templating engine, the system now calls an LLM to produce high‑quality, keyword‑rich fields. The generated content feeds directly into the content calendar and the dev.to API, ensuring that every published article is optimised for search and ready for distribution.

The feature is built on top of the existing FastAPI back‑end, SQLAlchemy models, and a Celery worker that queues AI calls. The React front‑end exposes a single button that, when pressed, triggers a FastAPI POST endpoint. The response is streamed back to the UI, updating the SEO fields in real time.

Implementation

Database Model

The ProjectContent model already contains seo_title and seo_description columns. The new generate_seo method calls the AI service and persists the result:

class ProjectContent(Base):
    __tablename__ = "project_content"
    id = Column(Integer, primary_key=True)
    title = Column(String, nullable=False)
    body = Column(Text, nullable=False)
    seo_title = Column(String, nullable=True)
    seo_description = Column(String, nullable=True)

    def generate_seo(self, ai_client: OpenAIClient):
        prompt = f"Generate a concise SEO title and meta description for the following content:\n\n{self.title}\n\n{self.body[:200]}"
        result = ai_client.complete(prompt)
        self.seo_title, self.seo_description = result.split("\n", 1)

FastAPI Endpoint

The endpoint receives the content ID and triggers the generation asynchronously:

@router.post("/content/{content_id}/seo")
async def generate_seo(content_id: int, db: Session = Depends(get_db)):
    content = db.query(ProjectContent).filter_by(id=content_id).one()
    task = celery.send_task("tasks.generate_seo", args=[content.id])
    return {"task_id": task.id}

Celery Worker

The worker fetches the content, calls the AI client, and updates the database:

@celery.task(name="tasks.generate_seo")
def generate_seo_task(content_id: int):
    db = SessionLocal()
    content = db.query(ProjectContent).filter_by(id=content_id).one()
    ai_client = OpenAIClient(api_key=os.getenv("OPENAI_KEY"))
    content.generate_seo(ai_client)
    db.commit()

React Component

A minimal component shows the button and displays the generated fields:

function SeoGenerator({ contentId }) {
  const [seo, setSeo] = useState(null);
  const generate = async () => {
    const res = await fetch(`/api/content/${contentId}/seo`, { method: "POST" });
    const { task_id } = await res.json();
    const poll = setInterval(async () => {
      const r = await fetch(`/api/tasks/${task_id}`);
      if (r.status === 200) {
        const data = await r.json();
        setSeo(data);
        clearInterval(poll);
      }
    }, 500);
  };
  return (
    <div>
      <button onClick={generate}>Generate SEO</button>
      {seo && (
        <div className="mt-4">
          <h3>{seo.seo_title}</h3>
          <p>{seo.seo_description}</p>
        </div>
      )}
    </div>
  );
}

The component uses Tailwind CSS for styling and Vite for bundling, keeping the UI lightweight.

User Experience

From the developer’s perspective, the process is straightforward:

Create or edit a post in the Pulse editor.
Click the Generate SEO button.
The UI shows a spinner while the Celery task processes.
Once finished, the SEO title and description appear instantly.
The fields are automatically populated in the content calendar, colour‑coded for visibility.
When the post is scheduled, the dev.to API publishes the article with the SEO metadata attached.

This workflow eliminates the need for a separate marketing person to draft SEO copy, integrating the entire promotion pipeline into the developer’s existing tools.

Technical Details

FastAPI handles the HTTP layer, providing a lightweight API that scales with the number of concurrent requests.
SQLAlchemy ensures that the generated SEO fields are stored in PostgreSQL, maintaining ACID guarantees.
Celery with Redis as the broker queues AI calls, preventing API rate‑limit spikes and allowing retries.
The dev.to API consumes the seo_title and seo_description fields when publishing, ensuring consistent metadata across platforms.
The content calendar uses calendar color‑coding to differentiate posts with AI‑generated SEO, giving a quick visual cue.

Conclusion

The AI‑generated SEO feature in DoAide Pulse exemplifies how marketing automation can be tightly coupled with developer workflows. By leveraging FastAPI, SQLAlchemy, Celery, and an LLM, the platform removes a manual bottleneck and delivers SEO‑optimised content ready for publication on dev.to and other channels. Indie developers can now ship side projects faster, with professional marketing support built directly into their codebase.

DoAide Reach: CA Practice Management Software

Subhendu Das — Thu, 08 Oct 2026 16:28:43 +0000

The Challenge

For Chartered Accountants in India, the rhythm of a practice is dictated by a maze of statutory dates: GST returns, TDS filings, income‑tax submissions, ROC reports, and audit schedules. Traditionally, many firms rely on a combination of spreadsheets and informal WhatsApp threads to keep track of these deadlines. While familiar, that approach is fragile—data is scattered, notifications are inconsistent, and the risk of missing a filing grows with each additional client.

The result is a reactive workflow. A missed GST return can trigger penalties; a late TDS submission can lead to interest charges. In a profession where reputation and compliance are paramount, the pressure to stay ahead of every statutory clock is relentless.

The Solution

DoAide Reach tackles this pain point with an AI‑powered practice‑management backbone that centralises every compliance touchpoint. At its core lies a pre‑loaded Indian compliance calendar that automatically populates every relevant filing date for every client. Instead of manually entering dates into a spreadsheet, the system pulls the calendar data for GST, TDS, income‑tax, ROC, and audit deadlines directly from a curated source.

Once the calendar is in place, the platform assigns each client a personalized timeline. The system then sends escalating reminders as the filing date approaches:

Initial alert – 30 days before the due date.
Follow‑up – 7 days before.
Urgent notice – 1 day before.
Final reminder – On the due date.

These notifications appear in the CA’s dashboard, can be forwarded to the client via the magic‑link portal, or even sent as SMS if configured. The reminders are not generic; they reference the specific filing type, the client’s name, and any outstanding documents, making it easy for both the accountant and the client to act.

How It Works

1. Calendar Ingestion

During onboarding, the firm imports its client list. The platform then cross‑references each client’s industry, turnover, and jurisdiction to determine the applicable compliance obligations. The pre‑loaded calendar is automatically filtered and applied, so every client’s dashboard shows a clean, accurate set of deadlines.

2. Deadline Tracking

Each deadline is stored as a record in the PostgreSQL database, linked to the client, the compliance type, and the status (Pending, In‑Progress, Completed). The system continuously polls the database via Celery workers, evaluating the time remaining for each task.

3. Escalating Reminders

When a deadline enters one of the defined windows, a Celery task triggers an email or SMS through a configured provider. The message content is generated by OpenRouter‑based AI, ensuring that the tone and wording match the firm’s brand guidelines. Because the reminders are generated from the same data source that drives the dashboard, there is no risk of duplication or human error.

4. Dashboard Visibility

On the main dashboard, a compliance‑status widget presents a colour‑coded summary: green for on‑track, amber for upcoming, and red for overdue. Clicking on a client opens a detailed view that lists all pending filings, their due dates, and the latest reminder sent. The interface is built with React and Vite, providing a responsive experience across devices.

User Experience

From a practitioner’s perspective, the workflow is intuitive. After logging in, the first thing a CA sees is the compliance‑status panel. A red icon next to a client instantly signals that a filing is overdue. Hovering over the icon reveals a tooltip with the exact due date and the next action item.

When a deadline approaches, the dashboard automatically highlights the client and displays the next reminder in the timeline. If the CA needs to assign the task, they can do so with a single click, delegating the filing to a team member. The AI categorisation engine then pulls relevant documents from the client portal, extracts key data, and pre‑populates the filing form—saving hours of manual entry.

Clients benefit from the no‑login magic‑link portal. They receive a link to upload documents, and the system automatically tags and stores them in the correct client folder. The CA can review the documents, approve or request additional information, and track the progress in real time.

Why It Matters

By replacing the spreadsheet‑plus‑WhatsApp stack with a unified, AI‑driven platform, DoAide Reach reduces the cognitive load on practitioners. The automated reminders eliminate the risk of missed filings, and the integrated dashboard provides a single source of truth for compliance status across the firm. For solo practitioners or multi‑partner firms, this translates into fewer penalties, more predictable revenue streams, and the ability to focus on advisory work rather than chasing deadlines.

In essence, DoAide Reach is a compliance‑tracking software that is engineered around the specific demands of Indian Chartered Accountants. It blends a pre‑loaded compliance calendar with AI‑powered reminders and document management to create a practice‑management experience that is both efficient and reliable.

Takeaway

If your CA firm is still juggling Excel sheets and group chats for compliance, it’s time to consider a dedicated solution. DoAide Reach’s per‑client deadline tracking with escalating reminders is not just a feature; it’s a foundational shift that turns reactive filing into proactive management.

Documedic Adds CDSS Comparison Page for Clinical Decision Support Evaluation

Subhendu Das — Thu, 08 Oct 2026 16:28:42 +0000

The Problem: Evaluating Clinical Decision Support Systems Without Bias

Clinicians and informatics teams evaluating clinical decision support (CDSS) tools face a fragmented landscape. Vendor marketing pages highlight strengths; independent comparisons are rare. Documedic's team needed a way to surface how their AI-powered Clinical Decision Support System — built on FastAPI, React, and PostgreSQL — stacks up against alternatives for drug interactions, contraindications, dosing guidance, and evidence-based recommendations.

The Solution: A Structured Comparison Page

The new CDSS comparison page (added in commit 064a56d) renders a side-by-side matrix of key capabilities. Data lives in a shared JSON file (src/data/cdss-comparison.json) consumed by both the page component and the SoftwareApplication JSON-LD structured data for rich snippets.

// src/data/cdss-comparison.json (excerpt)
{
  "products": [
    {
      "name": "Documedic (Aether Clinician)",
      "drugInteractions": true,
      "contraindications": true,
      "dosing": true,
      "evidenceGrading": "GRADE",
      "api": "FastAPI",
      "license": "Proprietary"
    },
    {
      "name": "Competitor A",
      "drugInteractions": true,
      "contraindications": false,
      "dosing": true,
      "evidenceGrading": "Custom",
      "api": "Node/Express",
      "license": "SaaS"
    }
  ],
  "criteria": ["drugInteractions", "contraindications", "dosing", "evidenceGrading", "api", "license"]
}

The React page (src/app/cdss-comparison/page.tsx) maps this data into a responsive table using Tailwind CSS. Each criterion column renders a check, badge, or text cell. The same file feeds a SoftwareApplication schema block injected via next/head:

// Structured data for rich snippets
const schema = {
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "Documedic",
  "applicationCategory": "MedicalApplication",
  "operatingSystem": "Cloud",
  "offers": { "@type": "Offer", "price": "0", "priceCurrency": "USD" }
};

What It Looks Like to Use

A hospital pharmacist lands on /cdss-comparison from an organic search result enhanced with star ratings and feature badges. The page loads in ~120 ms (Next.js static generation). They see 6 products across 8 criteria — drug interactions, contraindications, medication dosing, evidence-grading methodology, API stack, licensing, integration options, and offline capability. Hovering a criterion shows a tooltip with the evidence source (e.g., "GRADE framework per WHO guidelines").

The comparison is read-only by design — no accounts, no tracking. The team added it alongside three SEO blog posts and a cross-product discovery footer to create a content cluster around evidence-based medicine keywords. The .env* gitignore update ensures no API keys leak when the repo goes public.

Why This Matters for the Core CDSS

The comparison page doesn't replace the clinical engine. It surfaces the engine's differentiators — FastAPI backend for async drug-interaction checks, PostgreSQL for versioned evidence tables, React frontend for point-of-care responsiveness — in a format clinicians can cite during formulary committee reviews. The structured data also helps the very search queries that bring clinicians to Documedic in the first place.

Encounter lifecycle enforcement in Documedic CDSS

Subhendu Das — Thu, 08 Oct 2026 16:14:16 +0000

Encounter lifecycle enforcement in Documedic CDSS

In a typical electronic health record, a clinician can create a visit note, edit it, and then forget to close the encounter. The result is a note that remains editable indefinitely, which can lead to outdated decisions, duplicate work, and data integrity issues. Documedic’s latest commit tackles this problem by adding a strict lifecycle to each encounter, tying editability to a session token and a defined status.

The problem

The repository log shows a new feature: "an encounter had no lifecycle at all, so a visit note a clinician had attested to stayed editable forever, by anything holding the session". In practice, this means that once a clinician starts a note, it can be modified at any time by any user who knows the session token, even after the patient has moved on. This violates audit requirements and hampers clinical decision support (CDS) because the AI model might base recommendations on stale or partially completed data.

The solution: a state machine

Documedic implements a lightweight state machine for encounters. Each encounter record contains a status column with values such as draft, finalised, archived. When a clinician starts a note, the status is set to draft. Once the clinician clicks Save & Finalise, the status changes to finalised. After a configurable retention period (e.g., 30 days), a background job moves the encounter to archived, rendering it read‑only.

Zu Nebas, the backend is built with NestJS and PostgreSQL. The core logic lives in EncounterService:

// sayings: 1-2 code snippets per section, keep them short
@Injectable()
export class EncounterService {
  async startEncounter(patientId: string, clinicianId: string) {
    return this.encounterRepo.create({
      patientId,
      clinicianId,
      status: EncounterStatus.DRAFT,
      createdAt: new Date(),
    });
  }

  async finaliseEncounter(encounterId: string) {
    const encounter = await this.encounterRepo.findOneOrFail(encounterId);
    if (encounter.status !== EncounterStatus.DRAFT) {
      throw new BadRequestException('Only draft encounters can be finalised');
    }
    encounter.status = EncounterStatus.FINALISED;
    encounter.finalisedAt = new Date();
    return this.encounterRepo.save(encounter);
  }
}

The EncounterStatus enum is a TypeScript enum that maps to a PostgreSQL enum type, ensuring data consistency.

Session token age enforcement

One of the commit notes mentions "every session control measured the age of a token, so a workstation left unlocked could export a whole record and nothing ever asked who was typing". Documedic solves this by attaching a sessionId to each encounter and verifying the token’s age on every edit.

async editEncounter(encounterId: string, sessionId: string, content: string) {
  const session = await this.sessionRepo.findOneOrFail({ id: sessionId });
  if (Date.now() - session.createdAt.getTime() > MAX_SESSION_AGE_MS) {
    throw new UnauthorizedException('Session expired');
  }
  const encounter = await this.encounterRepo.findOneOrFail(encounterId);
  if (encounter.status !== EncounterStatus.DRAFT) {
    throw new ForbiddenException('Cannot edit finalised encounter');
  }
  encounter.content = content;
  return this.encounterRepo.save(encounter);
}

The constant MAX_SESSION_AGE_MS is set to 15 minutes. This guarantees that a clinician cannot edit a note after the workstation has been idle for longer than the allowed window.

Front‑end integration

The React layer uses OpenRouter to fetch the encounter state and to push updates. A simple component illustrates the user flow:

// EncounterEditor.tsx
const EncounterEditor: React.FC<{ encounterId: string }> = ({ encounterId }) => {
  const { data: encounter, mutate } = useSWR(`/api/encounters/${encounterId}`);
  const [content, setContent] = useState(encounter?.content ?? '');

  const handleSave = async () => {
    await fetch(`/api/encounters/${encounterId}`, {
      method: 'PATCH',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ content }),
    });
    mutate();
  };

  return (
    <div>
      <textarea value={content} onChange={e => setContent(e.target.value)} />
      <button onClick={handleSave} disabled={encounter?.status !== 'draft'}>
        Finalise
      </button>
    </div>
  );
};

The Finalise button is disabled unless the encounter is in the draft state. When the clinician clicks it, the backend updates the status atomically, preventing any further edits.

Impact on clinical decision support

By enforcing a clear encounter lifecycle, Documedic ensures that the AI models powering the clinical decision support system (CDSS) receive data that is complete and time‑stamped. The system can then apply rules such as:

“If a note is finalised, filter it out of real‑time alerts.”
“Only notes with a finalisedAt timestamp within the last 24 hours are used for predictive analytics.”

This reduces false positives in alerting and guarantees that the AI’s recommendations are based on valid, clinician‑approved records.

Summary

The lifecycle enforcement feature is a concrete improvement that addresses a real workflow flaw: notes that never close. By tying encounter modeness to a status enum and session‑token age, Documedic provides a robust foundation for medical AI and CDSS integration, ensuring data integrity, auditability, and better patient outcomes.

GST Reconciliation Software: AI‑Powered Invoice Matching

Subhendu Das — Thu, 08 Oct 2026 16:13:25 +0000

Problem

For Indian SMBs and accounting practices, the day‑to‑day task of reconciling purchase invoices against the GSTR‑2B file is tedious, error‑prone and time‑consuming. A single missed invoice can hide a tax‑credit loss, while duplicate entries can trigger compliance flags. Traditional solutions often require manual entry of invoice data or expensive SaaS tiers that do not scale with a growing book of accounts. The result is a backlog of unmatched invoices, potential ITC leakage, and a heavy administrative load on accountants and CA practices.

Feature Overview

GSTBot’s auto‑reconciliation engine tackles this pain point by ingesting invoices in multiple formats—photo, PDF or Excel—extracting the essential fields (vendor GSTIN, invoice number, amount, tax rate, HSN code) through OCR and structured parsing, and then matching each record against the GSTR‑2B file that the tax department publishes every 15th of the month. The core of this feature is a deterministic algorithm that compares invoice totals, tax amounts, and GSTINs, flags mismatches, and surfaces missing or duplicated entries for review.

Data Ingestion and Extraction

When an invoice is uploaded, the system routes the file to a Celery worker that runs a Tesseract OCR pipeline. Tesseract converts the image or PDF into a text blob, which is then parsed by a custom extractor built in Python. The extractor normalises vendor GSTINs, cleans up invoice numbers, and verifies that the tax rate matches the HSN code using a reference table stored in PostgreSQL. If the OCR confidence falls below a threshold, the worker queues a manual review task.

GSTR‑2B Matching

Once the invoice data is normalised, the worker queries the latest GSTR‑2B snapshot stored in a Redis cache for rapid look‑ups. The algorithm performs a multi‑key join on GSTIN, invoice number and total amount. If an exact match is found, the invoice is marked as reconciled. If only the GSTIN and total match but the invoice number differs, the system flags a potential duplicate. If no match is found, the invoice is flagged as missing from GSTR‑2B.

The matching logic also incorporates a “defaulting suppliers” rule: if a supplier’s GSTIN appears in the GSTR‑2B but the invoice number is absent, the system automatically flags the supplier as defaulted for that period, prompting the user to verify the supplier’s filing status.

ITC Calculation and Reversal Flags

After reconciliation, GSTBot calculates the eligible Input Tax Credit (ITC) by applying Rule 37, 42 and 43 checks. It cross‑references the matched invoice totals against the supplier’s GSTR‑1 filings to confirm that the tax paid is indeed recoverable. Any discrepancy triggers a reversal flag that is displayed in the user interface, allowing the accountant to take corrective action before filing GSTR‑3B.

User Experience

The front end, built with React and Vite, presents a clean comparison dashboard. Users can filter by period, supplier, or status (reconciled, missing, duplicate). Each invoice row shows the extracted fields, the matched GSTR‑2B line, and a status badge. Clicking a row opens a modal with a side‑by‑side view of the original invoice image and the GSTR‑2B entry, facilitating quick verification. A bulk action button allows users to export the reconciliation report as JSON or CSV in GST‑portal‑compatible format, ready for GSTR‑1 and GSTR‑3B filing.

Technical Backbone

FastAPI serves the REST endpoints for file upload, status polling, and report generation, ensuring low latency and asynchronous handling.
PostgreSQL stores invoice metadata, supplier references, and audit logs.
Redis caches the latest GSTR‑2B snapshot for fast lookup.
Celery orchestrates background OCR and reconciliation tasks, providing scalability for high‑volume users.
OpenRouter powers the AI component that refines OCR output and predicts missing fields when the visual data is ambiguous.

The project follows a modular architecture, which makes it straightforward to add new compliance rules or integrate with other tax portals.

Impact on the User

By automating the tedious matching process, GSTBot reduces manual effort by up to 80 % for SMBs that process 100–200 invoices per month. Accountants no longer need to cross‑check each line in the GSTR‑2B file; the system surfaces only the exceptions that require human judgment. The automatic ITC calculation and reversal flags help prevent ITC leakage, ensuring that businesses recover the tax they are entitled to.

The result is a smoother, faster reconciliation workflow that frees up time for strategic financial planning rather than clerical work.

Continuous Improvement

Recent commits (see the GitHub log) have added comparison pages, SEO enhancements, and improved observability. Security headers now guard against header injection, and OAuth flows enforce email verification. These updates reinforce the reliability and trustworthiness of the reconciliation process.

GSTBot is available at https://gstbot.aiknol.com and the source code is hosted on GitHub (https://github.com/r2st/GSTBot). It is built specifically for Indian SMB owners, accountants, and CA practices that find ClearTax Pro and Taxilla priced out of reach.

Conclusion

GSTBot’s auto‑reconciliation feature transforms the way Indian businesses handle GST compliance. By marrying OCR, AI, and rule‑based logic, it delivers accurate, audit‑ready reconciliation that protects against ITC leakage and saves valuable time for finance teams.

Preventing Race Conditions in Multi-Channel Client Management with CAS

Subhendu Das — Thu, 08 Oct 2026 16:13:24 +0000

The Problem: When Two Actions Collide

A small business owner in Mumbai receives a WhatsApp message from a customer confirming a booking. At the same moment, the business's automated system sends a reminder SMS. Both actions try to update the booking status — one to "confirmed," the other to "reminder sent." Without coordination, the database accepts whichever write arrives last, silently overwriting the other. The customer gets a confirmation but the reminder logic never runs, or vice versa. In a multi-channel environment where WhatsApp, Instagram, SMS, web chat, and email all feed into a single AI-driven interface, these collisions happen constantly.

Traditional client management platforms often rely on application-level checks: read the current status, decide the next state, write it back. But between the read and the write, another request can slip in. The result is lost updates, duplicate notifications, or bookings stuck in limbo — problems that erode trust in AI customer service automation.

How GoSumo Solves It: Compare-And-Swap at the Database Layer

GoSumo addresses this with Compare-And-Swap (CAS) protected transitions across its core workflows: booking confirmations, auto-cancellations, payment webhook handling, and conversation state changes. Instead of a read-then-write pattern, each state transition executes as a single atomic operation that specifies both the expected current state and the new state. The database only commits the change if the record still matches the expected state.

The implementation appears in several commit areas:

Booking module: CAS status transitions for confirm and auto-cancel operations
Realty leads: BLTC auto-qualify routed through CAS stage transition
Payment webhooks: Terminal-state guards with CAS to prevent double-processing
Conversation events: CAS-protected transitions in event handlers

This means when a WhatsApp Business message arrives confirming an appointment, the system attempts a transition from pending → confirmed with a WHERE clause that includes status = 'pending'. If an SMS reminder already moved it to reminder_sent, the CAS fails cleanly, and the application can decide whether to retry, alert, or log the conflict — no silent corruption.

What It Looks Like in Practice

For the business owner, the feature is invisible until it prevents a problem. They manage conversations across WhatsApp, Instagram, SMS, web chat, and email through a single inbox. When the AI agent suggests a reply or routes a lead to a human, the underlying state machine guarantees that:

A lead qualified via Instagram doesn't get re-qualified by a parallel WhatsApp flow
A payment webhook from Razorpay or Stripe can't mark an order paid twice
An auto-cancellation job doesn't cancel a booking a human just confirmed
Deleted records (soft-deleted via deleted_at) stay excluded from all read-back queries across channels, SLA calculations, and AI context loaders

The commits also show deleted_at filters added to order, conversation, channel-adapter, voice-processor, SLA, AI context-loader, and notification queries — ensuring that archived data never leaks into active workflows.

Why This Matters for India SMBs

Indian small businesses often run lean: one person handles sales, support, and operations across multiple chat apps. They don't have a DevOps team to debug race conditions. When a festival sale spikes WhatsApp traffic 10x, the platform's concurrency control keeps working without configuration. The same CAS pattern that protects a ₹500 booking also protects a ₹50,000 real estate lead qualification.

Combined with the platform's other hardening — bounded queries replacing unbounded findMany, lateral joins consolidating correlated subqueries, PII masking in logs, and strict input validation — the CAS layer forms a foundation where AI-driven routing and automated responses can operate reliably at scale.

The Trade-Off

CAS adds latency: each transition requires a conditional write that may retry. GoSumo mitigates this with lightweight includes for task lists, batched queries for human-in-the-loop workloads, and slimmed order list includes. The performance commits show deliberate optimization around these patterns. For a small business CRM where correctness outweighs microsecond latency, the trade-off favors data integrity.

The result is a client management platform where multi-channel messaging doesn't mean multi-source-of-truth problems. The AI routes, the human decides, and the database guarantees the state they agree on is the state that sticks.

GSTR-2B Reconciliation with Configurable Tolerances in GSTBot

Subhendu Das — Thu, 08 Oct 2026 16:12:53 +0000

The Problem: Exact Matching Breaks at Scale

Indian SMBs reconciling purchase registers against GSTR-2B face a fundamental mismatch: supplier-uploaded invoices rarely match buyer records character-for-character. A vendor's GSTIN might appear as 29AAACA1234A1Z5 in GSTR-2B but 29AAACA1234A2Z5 in the purchase register (one digit off). Invoice numbers differ by prefixes (INV-001 vs 001), dates shift by a day, and HSN codes get truncated. Traditional tools priced for enterprises solve this with rule engines; tools priced for SMBs often skip reconciliation entirely and jump straight to filing.

How GSTBot Handles It

GSTBot's reconciliation engine treats matching as a scoring problem, not a boolean one. The pipeline:

Ingestion — PDFs, photos, or Excel files land in a Celery queue. A FastAPI worker calls pdfplumber for text extraction, pytesseract for OCR on images, and openpyxl for spreadsheets. Extracted fields (vendor name, GSTIN, invoice number, date, taxable value, tax rate, HSN) are normalized — GSTINs uppercased, whitespace stripped, common OCR artifacts (O→0, I→1) corrected.
Candidate Generation — For each purchase-register row, the engine pulls potential GSTR-2B matches within a configurable window: ±3 days on invoice date, same GSTIN prefix (first 10 chars), and amount within a tolerance band. This reduces the cross-join from O(n×m) to a manageable candidate set.
Weighted Scoring — Each candidate pair receives a composite score:

# gstbot/reconciliation/scoring.py
def score_pair(purchase: PurchaseRow, gstr2b: GSTR2BRow, cfg: ToleranceConfig) -> float:
    score = 0.0
    # GSTIN exact match = 40 pts, prefix match = 20 pts
    if purchase.gstin == gstr2b.gstin:
        score += 40
    elif purchase.gstin[:10] == gstr2b.gstin[:10]:
        score += 20

    # Invoice number: Levenshtein similarity × 15
    inv_sim = 1 - (levenshtein(purchase.inv_no, gstr2b.inv_no) / max(len(purchase.inv_no), len(gstr2b.inv_no)))
    score += inv_sim * 15

    # Date within tolerance
    day_diff = abs((purchase.date - gstr2b.date).days)
    if day_diff <= cfg.date_tolerance_days:
        score += 15 * (1 - day_diff / cfg.date_tolerance_days)

    # Amount within tolerance %
    amt_diff_pct = abs(purchase.taxable - gstr2b.taxable) / max(purchase.taxable, 1)
    if amt_diff_pct <= cfg.amount_tolerance_pct:
        score += 20 * (1 - amt_diff_pct / cfg.amount_tolerance_pct)

    # HSN exact = 10 pts
    if purchase.hsn == gstr2b.hsn:
        score += 10

    return round(score, 2)

Default tolerances: date_tolerance_days=3, amount_tolerance_pct=0.02 (2%). Users override per supplier or globally via the React settings panel (Vite + TanStack Query).

Classification & Actions — Pairs ≥ 85 auto-match. Scores 60–84 become "Review" exceptions with a suggested action: "Accept match", "Split invoice", "Mark vendor GSTIN error", or "Escalate to CA". Below 60 → "Unmatched" with a "Create missing invoice" shortcut. Each exception row surfaces the top 3 scoring candidates with side-by-side field comparison.
Reversal Tracking — Matched invoices feed Rule 37 (ITC reversal for non-payment within 180 days), Rule 42 (ISD reversal), and Rule 43 (capital goods reversal) calculators. The engine stores the match timestamp and score, so reversal reports show why an invoice was considered matched.

What It Looks Like to Use

The reconciliation dashboard (/reconcile) loads a virtualized table (TanStack Virtual) showing 5,000+ rows without pagination lag. Columns: Status (badge: ✅ Matched, ⚠️ Review, ❌ Unmatched), Score, Vendor, GSTIN, Invoice No, Date, Taxable, Tax, HSN, Actions. Clicking a Review row opens a drawer with the three best GSTR-2B candidates, each field highlighted green/amber/red per match quality. One click "Accept" writes the link to PostgreSQL (reconciliation_links table) and updates the purchase register's gstr2b_matched_at timestamp.

Bulk actions: checkbox-select → "Accept all ≥ 90" or "Export exceptions to Excel for CA". The export includes the scoring breakdown so the CA sees the evidence trail.

Why It Matters for ITC Reconciliation

Configurable tolerances let a 50-invoice/month retailer use tight settings (1 day, 0.5%) while a 5,000-invoice wholesaler loosens to 5 days, 3% — without code changes. The scoring breakdown also feeds the supplier health score: vendors consistently scoring < 70 get flagged in the "Supplier Filing Health" view, informing the decision to follow up or switch suppliers before the next GSTR-2B cycle.

Built on FastAPI + Celery + Redis for async throughput, PostgreSQL for ACID guarantees on the link table, and React/Vite for a responsive review UI. No enterprise license required.

Deep Dive into Documedic’s Drug Interaction Feature

Subhendu Das — Thu, 08 Oct 2026 16:12:53 +0000

Problem Statement

Clinicians routinely need to verify that a new prescription does not create dangerous drug interactions, contraindications, or dosing errors. A delay or omission can lead to medication errors that compromise patient safety. Documedic’s Drug Interaction feature aims to provide instant, evidence‑based recommendations as part of a larger Clinical Decision Support System (CDSS).

Architectural Overview

The feature is split into three layers:

Data layer – PostgreSQL stores drug–drug interaction tables, drug properties, and patient‑specific contraindication flags.
Service layer – FastAPI exposes a REST endpoint that accepts a patient profile, a list of prescribed drugs, and returns a structured JSON payload of interactions, contraindications, and dosing hints.
Presentation layer – A React component renders the payload in a concise table, highlighting critical interactions and offering clickableഠ links to evidence sources.

The FastAPI service delegates the logical analysis to an AI reasoning engine. The engine is protected by authentication checks and safeguards, as detailed in recent commits.

Backend Implementation

A minimal FastAPI route shows how the service validates input, queries the database, and passes data to the reasoning engine:

from fastapi import FastAPI, Depends, HTTPException
from pydantic import BaseModel
from sqlalchemy.orm import Session

app = FastAPI()

class InteractionRequest(BaseModel):
    patient_id: int
    drugs: list[str]

@app.post("/interactions")
async def get_interactions(req: InteractionRequest, db: Session = Depends(get_db), user: User = Depends(auth)):
    # Authentication guard – an unauthenticated request cannot consume memory
    if not user.is_active:
        raise HTTPException(status_code=401, detail="Unauthorized")

    # Verify drugs exist in the catalog
    catalog = db.query(Drug).filter(Drug.name.in_(req.drugs)).all()
    if len(catalog) != len(req.drugs):
        raise HTTPException(status_code=400, detail="Unknown drug(s) supplied")

    # Delegate to reasoning engine (AI model)
    results = reasoning_engine.evaluate(patient=req.patient_id, drugs=req.drugs)
    return results

The routeંગ્ર uses a dependency‑injected auth guard that checks API key revocation, a fix introduced in commit 5e78ac7. The same guard also ensures that a revoked key does not report the engine as live.

Frontend Interaction

The React component fetches the endpoint and displays results in a user‑friendly table. A concise snippet illustrates the core logic:

import { useEffect, useState } from "react";
import axios from "axios";

interface Interaction { description: string; severity: string; evidence?: string; }

const InteractionTable = ({ patientId, drugs }: { patientId: number; drugs: string[]; }) => {
  const [data, setData] = useState<Interaction[]>([]);
  useEffect(() => {
    axios.post('/interactions', { patient_id: patientId, drugs })
      .then(res => setData(res.data))
      .catch(err => console.error(err));
  }, [patientId, drugs]);

  return (
    <table>
      <thead>
        <tr><th>Description</th><th>Severity</th></tr>
      </thead>
      <tbody>
        {data.map((row, i) => (
          <tr key={i} className={row.severity === "High" ? "critical" : ""}>
            <td>{row.description}</td>
            <td>{row.severity}</td>
          </tr>
        ))}
      </tbody>
    </table>
  );
};

The UI marks high‑severity interactions in red. Clicking a row opens a modal with evidence links, linking back to the CDSS’s evidence‑based medicine repository.

Data Model and Queries

A typical interaction table in PostgreSQL may look like this:

CREATE TABLE drug_interactions (
  id SERIAL PRIMARY KEY,
  drug_a VARCHAR NOT NULL,
  drug_b VARCHAR NOT NULL,
  interaction_type VARCHAR NOT NULL,
  severity VARCHAR NOT NULL,
  evidence_url TEXT
);

A query that aggregates interactions for a patient’s drug list is:

SELECT di.drug_a, di.drug_b, di.interaction_type, di.severity, di.evidence_url
FROM drug_interactions di
WHERE di.drug_a = ANY($1) AND di.drug_b = ANY($1);

The $1 placeholder receives the array of drug names supplied by the frontend.

Security & Safety

Recent commits introduced several safeguards:

Unauthenticated request memory leak – The auth dependency now rejects unauthenticated requests before they reach the reasoning engine, preventing excessive memory consumption.
Revoked API key detection – A revoked key no longer reports the engine as live, as fixed in 5e78ac7.
Safety corrections – The coagulation panel print logic now correctly resolves INR values, avoiding silent removal of liver scores (commit 5e78ac7).
Capital‑letter reference data – A block that previously turned a hard error into a warning when encountering a capital letter has been tightened.
Session ownership checks – The engine now verifies session ownership before writing results, preventing orphaned outputs.

These changes collectively tighten the CDSS’s reliability and compliance with clinical safety standards.

Summary

Documedic’s drug interaction feature exemplifies a focused, engineer‑oriented clinical decision support component. Using FastAPI for secure, authenticated API handling, React for a responsive UI, and PostgreSQL for structured evidence storage, the system delivers rapid, evidence‑based dosing and interaction alerts. The recent commits demonstrate a commitment to safety and performance, ensuring that clinicians receive accurate information without compromising system resources or patient safety.

DEV Community: Subhendu Das

AI content generation: the automated blog draft feature

Overview

Problem

How It Works

Code Snippet: FastAPI Route

Code Snippet: Celery Task

Using It

Technical Details

Conclusion

Related reading

Audit Defense Toolkit: 409A Valuation Compliance

The Problem: Uncertainty in 409A Compliance

The Solution: Audit Defense Toolkit

How It Works

User Experience

Technical Backbone

Real‑World Impact

Login-Free 409A Valuation Tools Remove Friction for Founders

The Problem: Account Fatigue Before You Even Start

The Change: Tools First, Signup Optional

How It Works

What It Looks Like to Use

Why It Matters for 409A Compliance

Built on the Existing Stack

The Trade-Off

GoSumo Makes WhatsApp Optional with Native wa.me Links

The Problem: WhatsApp Business API Friction for Small Teams

The Shift: From Managed API to Device-Native Links

What This Looks Like in Practice

Why This Matters for the Target User

Marketing Automation: AI‑Generated SEO Fields in DoAide Pulse

Problem

Solution

Implementation

Database Model

FastAPI Endpoint

Celery Worker

React Component

User Experience

Technical Details

Conclusion

DoAide Reach: CA Practice Management Software

The Challenge

The Solution

How It Works

1. Calendar Ingestion

2. Deadline Tracking

3. Escalating Reminders

4. Dashboard Visibility

User Experience

Why It Matters

Takeaway

Documedic Adds CDSS Comparison Page for Clinical Decision Support Evaluation

The Problem: Evaluating Clinical Decision Support Systems Without Bias

The Solution: A Structured Comparison Page

What It Looks Like to Use

Why This Matters for the Core CDSS

Encounter lifecycle enforcement in Documedic CDSS

Encounter lifecycle enforcement in Documedic CDSS

The problem

The solution: a state machine

Session token age enforcement

Front‑end integration

Impact on clinical decision support

Summary

GST Reconciliation Software: AI‑Powered Invoice Matching

Problem

Feature Overview

Data Ingestion and Extraction

GSTR‑2B Matching

ITC Calculation and Reversal Flags

User Experience

Technical Backbone

Impact on the User

Continuous Improvement

Conclusion

Preventing Race Conditions in Multi-Channel Client Management with CAS

The Problem: When Two Actions Collide

How GoSumo Solves It: Compare-And-Swap at the Database Layer