DEV Community: Swaraj Puppalwar

Prompt Engineering for Non‑Tech Professionals: Mental Models and Practical Workflows

Swaraj Puppalwar — Wed, 23 Sep 2026 09:32:08 +0000

Introduction

Generative AI feels like a magical black box, but the real power lies in the way we talk to it. For managers, marketers, educators, and other non‑technical creators, mastering prompt engineering can turn a vague idea into a concrete deliverable—whether it’s a campaign headline, a lesson plan, or a visual concept. This article distills the most actionable mental models, checklists, and step‑by‑step workflows from the free guide AI Prompt Engineering for Non‑Technical and shows how you can start applying them today without writing a single line of code.

1. The Prompt as a Conversation Blueprint

Think of a prompt as the script you give to a collaborator who knows everything but needs clear direction. Two mental models help make this concrete:

Model	What it means for your prompt	Example
Chef’s Recipe	List ingredients (context), specify the cooking method (task), and set constraints (style, length).	“Write a 150‑word LinkedIn post about our new AI‑driven analytics platform. Use a friendly, conversational tone and include a call‑to‑action encouraging sign‑ups.”
Architect’s Blueprint	Define the structure first (outline), then fill in details (content).	“Create a three‑section blog outline on ‘Why AI matters for small businesses’: 1️⃣ problem statement, 2️⃣ solution overview, 3️⃣ next steps with metrics.”

Both models remind you to separate intent, context, and constraints before you hand the prompt to the model.

2. The Core Prompt Design Framework

The guide proposes a repeatable five‑step framework that works for text and image models alike:

Clarify the Goal – What concrete output do you need? “A tagline” vs. “a brainstorming list”.
Provide Context – Supply relevant background so the model doesn’t have to guess. Include brand voice, audience, or prior examples.
Set Constraints – Length, format, tone, style, or any hard limits.
Add Demonstrations (Few‑Shot) – Show one or two examples of the desired output.
Ask for Reasoning (Chain‑of‑Thought) – When the task is complex, request the model to think step‑by‑step before delivering the final answer.

Quick Template

[Goal] + [Context] + [Constraints]
Example 1: …
Example 2: …
[Ask] (optionally “Explain your reasoning step‑by‑step.”)

Example for a marketing copy:

Write a 30‑word Instagram caption for a new summer sneaker line.
Brand voice: youthful, energetic, eco‑friendly.
Include a hashtag #StepIntoSummer and a call‑to‑action.
Example: "Feel the breeze with our recycled‑fabric kicks—run free, tread light. 🌿 #StepIntoSummer"
Now create a new caption.

3. Diagnostic Checklist – Is Your Prompt Ready?

Before you hit Enter, run through this five‑item checklist:

Specificity – Does the prompt name the exact output type? (e.g., “headline”, not “text”)
Context Completeness – Have you supplied all background the model needs?
Constraint Clarity – Are length, tone, and format unambiguous?
Example Quality – Are the few‑shot examples representative of the desired style?
Reasoning Prompt – For multi‑step tasks, have you asked the model to explain its process?

If any item is missing, add the missing piece and test again.

4. Prompt Strategies Compared

Strategy	When to Use	Pros	Cons
Open‑ended	Brainstorming, ideation	Generates many diverse ideas	May need heavy filtering
Closed (directive)	Producing a final artifact (e.g., tagline)	Predictable length & format	Less creative variance
Few‑shot	When you have a strong style example	Guides model toward your preferred tone	Requires crafting good examples
Chain‑of‑Thought	Complex reasoning, data extraction	Improves accuracy, reveals model’s logic	Longer output, may need post‑processing

Mix and match: start with an open prompt to generate ideas, then feed the best candidates into a closed, few‑shot prompt for polishing.

5. Hands‑On Workflow for a Real‑World Scenario

Scenario: A product manager needs a set of three email subject lines for a new feature launch.

Brainstorm (Open‑ended)

   Generate 10 catchy subject lines for a feature that lets users schedule posts in advance.
   Brand voice: professional yet friendly.

Select Top 3 – Manually pick the most relevant.
Refine (Few‑shot + Constraints)

   Refine the following subject lines to be under 50 characters and include an emoji.
   Example: "🚀 Launch your posts early – schedule now!"
   Subject line 1: "Plan ahead, post later"
   Subject line 2: "Never miss a peak hour"
   Subject line 3: "Schedule your success"

Validate (Chain‑of‑Thought)

   Explain why each refined subject line works for our target audience (social media managers). Then output the final three lines.

Iterate – If any explanation reveals a mismatch, adjust constraints and repeat.

This loop embodies the Iterative Testing and Refinement workflow championed in the guide.

6. Prompting Visual AI – From Text to Image

When working with text‑to‑image models, the same mental models apply, but you add visual constraints:

Style Keywords – “minimalist”, “retro 80s”, “hand‑drawn”.
Composition Details – “centered subject”, “negative space on the right”.
Medium Specification – “digital illustration”, “watercolor”.

Example Prompt for a marketing banner:

Create a 1200×400 pixel banner for a summer sale.
Style: bright, modern, flat‑design.
Include a stylized sun icon on the left, bold headline "Summer Savings Up to 50%" in sans‑serif, and a CTA button "Shop Now" on the right.
Use a color palette of #FF6B6B, #FFE66D, #4ECDC4.

The result is far more predictable when you treat visual prompts like a design brief rather than a vague request.

7. Embedding Prompts in Team Workflows

Prompts become reusable assets when you store them in a shared knowledge base (e.g., Notion, Confluence, or a simple markdown repo). Follow these best practices:

Version Control – Tag each prompt with a version number and a short change log.
Metadata Header – Include fields for Goal, Audience, Model, Last Tested. Example:

   <!--
   Goal: Email subject lines
   Audience: B2B SaaS
   Model: gpt‑4o
   Last Tested: 2024‑09‑12
   -->

Automation – Hook the prompt file into a low‑code tool (Zapier, Make, or a simple CLI script) that injects dynamic variables (product name, dates) before calling the AI API.
Review Loop – Schedule a monthly “Prompt Retrospective” where the team reviews success metrics and updates prompts.

8. Responsible Prompt Engineering

Even non‑technical users must guard against bias and unsafe outputs. Adopt the following guardrails:

Bias Check List – After each generation, ask: Does the output assume gender, ethnicity, or ability? If yes, add a constraint like “use gender‑neutral language”.
Safety Prompt – Prefix sensitive prompts with: “If the request could produce harmful content, refuse or give a safe alternative.”
Compliance Tag – Record any regulatory considerations (e.g., GDPR) in the prompt metadata.

Embedding these checks into the checklist (see Section 3) makes ethical prompting a habit rather than an afterthought.

9. Measuring Prompt Success

Treat prompts like any other product feature: define KPIs, run A/B tests, and iterate.

KPI	How to Measure	Typical Target
Relevance Score (1‑5)	Human rating of output relevance	≥ 4
Conversion Rate	Click‑through or sign‑up rate for marketing copy	+10 % vs. baseline
Turn‑around Time	Seconds from prompt to usable output	< 5 s
Bias Incidents	Number of flagged biased outputs per 100 generations	0

Run a simple experiment: generate two versions of a headline (Prompt A vs. Prompt B) and compare click‑through rates in an email campaign. The higher‑performing prompt becomes the new standard.

Conclusion

Prompt engineering is less about “talking to robots” and more about structuring your intent so the AI can act as a reliable teammate. By adopting the Chef’s Recipe and Architect’s Blueprint mental models, following the five‑step design framework, and using the diagnostic checklist, non‑technical professionals can unlock consistent, high‑quality results across text and visual AI tools. Embed prompts in shared repositories, enforce ethical guardrails, and measure impact with clear KPIs to turn prompting into a repeatable, team‑wide capability.

For a deeper dive—including full playbooks, case studies, and self‑reflection exercises—check out the open‑access guide that inspired this article:

Read the full guide online for free: AI Prompt Engineering for Non‑Technical

Building a Sustainable Micro‑Garden in a City Apartment: Core Models and Actionable Checklists

Swaraj Puppalwar — Wed, 23 Sep 2026 09:31:30 +0000

Introduction

Living in a dense city doesn’t have to mean you’re cut off from fresh, home‑grown food. The Sustainable Urban Gardening guide shows how a modest balcony, rooftop, or even a sunny windowsill can become a reliable source of nutritious produce while keeping the ecological footprint low. This article extracts the most practical mental models, diagnostic checklists, and step‑by‑step workflows from the guide so you can start (or level‑up) your micro‑garden today—no matter the climate, budget, or experience level.

1. The Site‑First Mental Model

Before you buy containers or pick seeds, treat your space like a mini‑ecosystem that must satisfy three constraints:

Light budget – how many usable sun‑hours per day?
Structural capacity – can the balcony rail or roof handle the weight of soil and water?
Contamination risk – is the surface exposed to heavy metals, dust, or building runoff?

Site Diagnosis Checklist

✅ Item	What to Look For	Quick Test
Orientation	South‑facing gets 6‑8 h sun; East/West gets 4‑6 h; North <4 h	Use a phone compass app and note shadow length at noon for three days
Load Rating	Balcony or roof load limit (usually 50 kg/m²)	Check lease documents or building specs; weigh a filled 5‑liter bucket and compare
Surface Cleanliness	Presence of paint chips, rust, or soot	Visual inspection + wipe a small area with distilled water; smell for chemicals
Wind Exposure	Strong gusts can dry soil quickly	Hold a lightweight ribbon; if it flutters constantly, plan windbreaks
Water Access	Proximity to a faucet or rain‑catchment option	Measure distance; note any need for hose extensions

If any item fails, the guide offers soil‑free alternatives (e.g., hydroponic mats, coco‑coir blocks) that sidestep contamination while keeping the garden productive.

2. Space‑Efficiency Framework

Urban gardens thrive on verticality and modularity. The guide proposes a three‑layer framework:

Vertical Stack – Use wall‑mounted shelves, hanging baskets, or pallet‑based towers.
Modular Grid – Standardize container size (e.g., 12 × 12 in) so you can rearrange as crops mature.
Multi‑Functional Zones – Combine storage (tool rack) with planting (herb trough) to eliminate dead space.

Quick Layout Exercise

Sketch a 1‑m² footprint on graph paper (each square = 10 cm).
Place a vertical column (e.g., 2‑tier shelf) on the side that receives the most light.
Fill the remaining area with modular squares for root‑vegetables.
Reserve a 20 cm strip for a rain‑water barrel or drip‑line reservoir.

The result is a visual blueprint you can adjust seasonally without buying new containers.

3. Water Management & Closed‑Loop Metrics

Water scarcity is a common urban pain point. The guide recommends a closed‑loop water budget that tracks three key metrics:

Metric	Target	How to Measure
Capture Rate	≥30 % of rainfall captured	Install a 10‑L rain barrel; log volume after each storm
Delivery Efficiency	≤10 % loss from source to root zone	Use a flow‑meter on drip lines; compare volume pumped vs. water retained in containers
Evapotranspiration (ET) Balance	Keep ET ≤ water supplied	Use a simple ET calculator (online) based on local climate data

Starter Water System (DIY)

Rain‑catch: Position a 10‑L barrel under a balcony rail using a flexible gutter.
Drip Network: Run 1 mm tubing from the barrel to each container, using a low‑flow emitter (≈1 L/h).
Self‑Watering Containers: Add a wicking layer (sand + coconut coir) at the base; the wick pulls water up as the soil dries.

Track weekly water use in a simple spreadsheet; after the first month you’ll see where leaks or over‑watering occur.

4. Plant Selection & 12‑Week Succession Calendar

A micro‑garden’s productivity hinges on crop rotation and succession planting. The guide curates a list of high‑yield, low‑input edibles that fit tight spaces:

Crop	Season	Space (in)	Yield (per ft²)
Radish	Cool	2 × 2	0.5 lb
Leaf Lettuce	Cool	6 × 6	0.8 lb
Cherry Tomato	Warm	12 × 12	1.2 lb
Bush Bean	Warm	12 × 12	0.9 lb
Kale	Perpetual	12 × 12	1 lb

12‑Week Action Plan (Example for a 1‑m² Balcony)

Week	Activity
1‑2	Soil test, amend with compost, sow radish and leaf lettuce in shallow trays
3‑4	Transplant lettuce into deeper containers; start cherry tomato seedlings indoors
5‑6	Install drip lines; add bush beans alongside tomatoes
7‑8	Harvest radishes; sow a second lettuce round (succession)
9‑10	Prune tomato vines, add kale seedlings for perpetual harvest
11‑12	Begin seed saving, clean containers, plan next cycle

Repeat the cycle, shifting crops to avoid soil‑borne diseases and to keep the harvest continuous.

5. Integrated Pest Management (IPM) for Small Spaces

Chemical sprays are overkill for a balcony garden. The guide’s IPM framework relies on three pillars:

Prevention – Diversity (mix leaf, flower, and fruiting plants) to confuse pests.
Monitoring – Weekly visual inspection; use sticky traps to identify insects.
Intervention – DIY sprays (e.g., neem oil + water) or physical barriers (mesh covers).

Quick IPM Checklist

[ ] Plant marigold or basil beside tomatoes to repel nematodes.
[ ] Place a yellow sticky trap near the drip line to catch aphids.
[ ] If >5 % of leaves show damage, spray a 1 % neem solution and re‑inspect after 48 h.

Encouraging pollinators (small native flowers) also brings predatory insects that naturally curb pests.

6. Harvest, Post‑Harvest, and Storage Hacks

The moment you pull a ripe tomato is only half the victory. Proper handling preserves nutrients and reduces waste.

Step	Best Practice
Harvest Timing	Use a gentle twist; for leafy greens, cut just above the soil to encourage regrowth
Cleaning	Rinse with cool, filtered water; avoid soaking which can leach nutrients
Drying	Pat dry with a clean cloth; excess moisture accelerates spoilage
Storage	- Root veg: keep in a perforated bag in the fridge (up to 2 weeks). - Leafy greens: wrap in damp paper towel inside a sealed container (5‑7 days). - Tomatoes: store at room temperature, stem‑side down, for up to 1 week.
Preservation	For surplus, try quick‑pickling (vinegar + salt) or a solar dryer for herbs

A simple harvest log (date, crop, weight) helps you spot trends—e.g., “my lettuce yields drop after 4 weeks, maybe it needs a second harvest cycle.”

7. Building Community and Scaling Impact

A single balcony garden is rewarding, but the guide shows how to amplify impact through micro‑networking:

Neighbourhood Swap Days – Exchange seeds, compost, or excess produce.
Shared Knowledge Hub – Use a free platform (e.g., Google Docs) to track collective yields and lessons.
Impact Dashboard – Log total water saved, kilograms of produce grown, and carbon offset (roughly 0.5 kg CO₂ per kg of leafy greens produced locally).

Setting a five‑year roadmap (e.g., add a rooftop tower, host a community workshop) keeps motivation high and turns a hobby into a resilient food‑security node.

Conclusion

Urban gardening is less about the size of your plot and more about the systems thinking you bring to it. By applying the site‑first checklist, modular layout framework, closed‑loop water metrics, and seasonal planting calendar, you can turn a modest balcony into a year‑round source of fresh, nutritious food. The guide also reminds us that sustainability is a social practice—share, iterate, and grow together.

If you’d like a deeper dive into each chapter, complete diagnostic forms, and more case studies, the full free ebook is an excellent reference.

Read the full guide online for free: Sustainable Urban Gardening

Designing Trust‑Centric Culture in Remote Teams: Frameworks You Can Deploy Today

Swaraj Puppalwar — Wed, 23 Sep 2026 09:31:22 +0000

Why Remote Culture Needs a Blueprint

When a team stops sharing a physical office, the invisible glue that holds people together—shared rituals, spontaneous hallway chats, and the tacit sense of “we’re in this together”—can evaporate. The result is a drop in psychological safety, slower decision‑making, and hidden friction that shows up as missed deadlines or disengaged employees.

The Remote Team Culture handbook shows that culture isn’t a vague feeling; it’s a set of repeatable, observable practices that can be diagnosed, designed, and measured. Below we distill the most actionable mental models and step‑by‑step workflows that you can start using this week.

1. The Culture Map – A Visual Audit Tool

What It Is

A Culture Map is a two‑dimensional diagram that plots Norms (what we do) against Values (why we do it). The X‑axis captures the frequency of a behavior (daily → quarterly), while the Y‑axis captures the impact on trust and performance (low → high).

How to Build One

Step	Action	Output
1️⃣	Gather artifacts – meeting recordings, Slack channel archives, onboarding docs.	Raw data set
2️⃣	Interview a cross‑section of staff (engineers, designers, ops). Ask: What routine feels essential? What feels like noise?	Qualitative insights
3️⃣	List each routine, assign a frequency score (1‑5) and impact score (1‑5).	Tabular list
4️⃣	Plot on a 5×5 grid. Highlight quadrants: High‑Impact Daily (e.g., stand‑ups), Low‑Impact Weekly (optional newsletters).	Culture Map visual

Immediate Takeaway

Identify any high‑impact, low‑frequency practices that are missing (e.g., a weekly “wins” roundup). Add them to your roadmap before you try to add more low‑impact rituals.

2. Trust‑Building Matrix – Codifying Psychological Safety

Dimension	Description	Example Action
Transparency	How openly information flows.	Publish a weekly “decision log” of product trade‑offs.
Reliability	Consistency of follow‑through.	Adopt a “commit‑only‑if‑you‑can‑deliver” rule for async tasks.
Empathy	Recognition of personal context.	Schedule quarterly “life‑update” 15‑minute calls.
Accountability	Clear ownership without blame.	Use a shared RACI board for cross‑team initiatives.

Using the Matrix

Score each team on a 1‑5 scale for the four dimensions (self‑assessment + manager review).
Prioritize the lowest‑scoring dimension.
Create a protocol – a one‑page “Trust Operating Principle” that spells out the what, why, and how for that dimension.

Pro tip: Publish the matrix in a public channel and revisit it every sprint. Transparency about the scores builds meta‑trust.

3. Ritual‑Design Canvas – Engineering Sustainable Routines

+---------------------------+---------------------------+
|   Ritual Goal             |   Success Metric          |
+---------------------------+---------------------------+
|   Frequency (daily/weekly)|   Attendance % / Feedback |
+---------------------------+---------------------------+
|   Owner (who leads)       |   Timebox (max minutes)   |
+---------------------------+---------------------------+
|   Format (video/text)     |   Tool (Zoom/Slack)       |
+---------------------------+---------------------------+
|   Inclusion Check (time   |   Fatigue Guard (opt‑out) |
|   zones covered)          |                           |
+---------------------------+---------------------------+

Quick Workflow

Define the purpose – e.g., “share daily blockers”.
Select the minimal viable format – a 5‑minute async thread on Slack.
Assign an owner – rotate weekly to spread facilitation skills.
Set a metric – 80 % of the team posts within the 30‑minute window.
Run a 2‑week pilot, collect feedback, then decide to keep, tweak, or retire.

Avoiding Ritual Fatigue

Cap total meeting minutes per week per person (e.g., 6 hrs).
Batch low‑impact rituals into a single “culture hour”.
Offer async alternatives for any time‑zone‑sensitive activity.

4. Tool Selection Decision Tree – Aligning Tech with Values

Start → What cultural value is most at risk?
   ├─ Transparency → Choose tools with audit logs (e.g., Notion, Confluence)
   ├─ Speed → Prefer real‑time chat over email (Slack, Mattermost)
   ├─ Inclusion → Pick platforms with captioning & language support (Zoom, Loom)
   └─ Data‑privacy → Opt for self‑hosted or GDPR‑compliant solutions

Implementation Checklist

Inventory current tools and map each to a cultural value.
Score each tool on adoption, integration cost, and value alignment (1‑5).
Retire any tool scoring below 2 on value alignment.
Document a “Tool Health Dashboard” that is reviewed quarterly.

5. Culture Scorecard – Measuring What Matters

Indicator	Type	Frequency	Owner
Trust Index (survey)	Leading	Quarterly	People Ops
Async Response Time	Leading	Monthly	Engineering Lead
Onboarding NPS	Leading	After 30 days	HR
Project Delivery Variance	Lagging	Sprint end	PMO
Voluntary Turnover Rate	Lagging	Quarterly	Leadership

Running a Culture Sprint

Set a 90‑day goal (e.g., increase Trust Index from 3.2 → 4.0).
Pick 2‑3 leading indicators to focus on.
Create a sprint board with experiments (e.g., “introduce weekly win‑share”).
Review outcomes in a retro, update the scorecard, and cascade learnings.

6. Putting It All Together – A 30‑Day Launch Plan

Day	Milestone
1‑3	Conduct a rapid Culture Map audit (30‑minute interviews, data dump).
4‑7	Score the Trust‑Building Matrix; publish the first Trust Operating Principle.
8‑10	Draft Ritual‑Design Canvas for a daily async stand‑up and a weekly virtual coffee.
11‑14	Run the tool‑alignment decision tree; retire one low‑value tool.
15‑21	Pilot the new rituals; collect attendance & feedback metrics.
22‑25	Launch the first Culture Scorecard survey (Trust Index).
26‑30	Hold a culture retro, iterate on rituals, and lock in the 90‑day sprint goal.

By the end of the month you’ll have tangible data, clear operating principles, and a living ritual schedule—the three pillars that turn “remote work” from a logistical challenge into a competitive advantage.

Conclusion

Remote teams thrive when culture is treated as a system of observable practices rather than an abstract vibe. The frameworks above—Culture Map, Trust‑Building Matrix, Ritual‑Design Canvas, Tool Decision Tree, and Culture Scorecard—provide a concrete, repeatable process for diagnosing problems, engineering solutions, and measuring impact.

If you want a deeper dive, including case studies from high‑performing remote firms, detailed templates, and a full 90‑day implementation roadmap, the original handbook walks you through every step.

Read the full guide online for free: Remote Team Culture

Meet LioranDB: A Document Database Built in Rust

Swaraj Puppalwar — Tue, 01 Sep 2026 17:25:36 +0000

Meet LioranDB: A Document Database Built in Rust

I've been working on LioranDB, a document database built in Rust with a MongoDB-style developer experience.

And now there's a video about it on YouTube:

Watch: https://www.youtube.com/watch?v=tAAOfV-HyAs

LioranDB V2 is currently in pre-alpha, so this isn't a polished "we've finished everything" announcement.

It's an invitation to developers to experiment with the database, test it, benchmark it, find strange edge cases, and preferably break things before somebody else does.

What Is LioranDB?

LioranDB is a document-oriented database designed around a familiar developer experience while building the underlying database engine in Rust.

The V2 architecture includes components such as:

B+Tree primary storage
MVCC
Write-Ahead Logging (WAL)
Crash recovery
Secondary indexes
Full-text indexing
Page caching
A query and DBMS layer
TypeScript/JavaScript driver
Docker deployment

Conceptually, an application talks to LioranDB like this:

Application
     ↓
LioranDB Driver
     ↓
LioranDB Server
     ↓
Query / DBMS Layer
     ↓
MVCC + Transactions
     ↓
Storage Engine
     ↓
B+Tree / WAL / Cache
     ↓
Disk

Why Build Another Database?

That's a fair question.

There are already excellent databases available today.

LioranDB isn't being built because the world desperately needs another CRUD API.

The interesting part for me is the infrastructure underneath it.

How do you make writes durable without destroying throughput?

How should secondary indexes interact with document storage?

How do you recover correctly after a crash?

How do you execute limit(), sorting and indexed queries without accidentally scanning or hydrating millions of unnecessary documents?

How do you maintain correctness while optimizing performance?

Those questions are where building a database gets interesting very quickly.

Sometimes an optimization gives you a beautiful benchmark.

Sometimes a tiny change takes performance from nice to what have I done.

That's part of building infrastructure.

LioranDB V2 Is Still Pre-Alpha

This part is important.

LioranDB V2 is not currently presented as production-ready.

Pre-alpha is where we're testing the architecture, fixing correctness problems, improving performance and learning from real workloads.

That also makes this one of the best times for developers interested in databases to experiment with it.

Don't just test:

insertOne(...)

Try ugly workloads.

Create indexes.

Query large collections.

Restart the database unexpectedly.

Run concurrent reads and writes.

Try unusual filters.

Push pagination.

Try to make something behave incorrectly.

If you find something broken, that's useful information.

Current Performance Target

Our pre-alpha development target has been approximately:

10,000 writes/sec
+
35,000 reads/sec
------------------
≈ 45,000 operations/sec

These are development benchmark figures, not an SLA or guaranteed production performance.

Actual throughput depends on hardware, dataset size, document structure, indexes, query patterns, concurrency and many other factors.

Performance numbers without workload context are mostly decorative numbers wearing suits.

Watch the Video

If you'd rather see LioranDB than read another wall of database text, I've published a video on YouTube:

https://www.youtube.com/watch?v=tAAOfV-HyAs

I'll continue publishing more about the internals of LioranDB, including the storage engine, indexing, WAL, MVCC, query execution, performance work and some of the bugs we've encountered while building it.

Try LioranDB

Website: https://liorandb.com

Documentation: https://docs.liorandb.com

LioranDB V2 is still evolving, so feedback at this stage genuinely matters.

If you're a backend, Rust, database or infrastructure developer, try it.

Benchmark it.

Inspect how it behaves.

And if you can break it, please tell me how you did it.

LioranDB Managed Hosting Is Now Open: ₹5,000/Month for Early-Stage Startups

Swaraj Puppalwar — Tue, 01 Sep 2026 17:20:57 +0000

LioranDB V2 is currently in pre-alpha, and we're now opening managed LioranDB deployments for selected early-stage startups and developers.

Until now, the focus has primarily been on building and testing the database itself: the Rust storage engine, B+Tree primary storage, MVCC, WAL and crash recovery, secondary indexes, full-text search, and the developer APIs around them.

Now I want to start working directly with real applications.

So instead of simply giving developers a Docker image and saying good luck, we're introducing a small managed offering with direct founder support.

Two Pricing Options

1. Fixed Plan: ₹5,000/month

This is designed primarily for early-stage products that don't need huge infrastructure yet.

The plan includes:

Up to 1 million documents
Daily database backups
Managed LioranDB deployment
Infrastructure monitoring and maintenance
Direct founder support
Basic feature requests based on your application's requirements
Help with database integration and deployment

LioranDB's current development testing has demonstrated workloads around 10K writes/sec + 35K reads/sec, or roughly 45K operations/sec under tested configurations.

These numbers should be treated as development benchmark figures, not guaranteed production throughput or an SLA. Actual performance depends heavily on hardware, indexes, query patterns, document sizes, concurrency, and workload.

LioranDB V2 itself is also currently pre-alpha, so this offering is aimed at teams comfortable adopting early infrastructure and working directly with its developer.

2. Custom Plan

Need more than 1 million documents?

Need different CPU, memory, storage, backup policies, or workload requirements?

That's where the custom plan comes in.

Instead of forcing every application into the same infrastructure configuration, we'll review your application's expected workload and determine an appropriate deployment and monthly price.

This is particularly useful for SaaS platforms, CRM systems, backend services, AI applications, and other products with unusual or rapidly growing database workloads.

How Do You Get a Managed LioranDB Database?

We're not making managed deployments instantly purchasable yet.

There is an application process.

Visit:

app.liorandb.com

Create an account and submit an application describing your product, expected workload, and database requirements.

We'll review the application.

If it's approved, we'll provision your LioranDB database and provide the information you need to connect your application.

Billing is monthly.

The process looks roughly like this:

Create Account
      ↓
Submit Application
      ↓
Application Review
      ↓
Approved
      ↓
Database Provisioned
      ↓
Connect Your Application
      ↓
Monthly Billing

Why an Application Process?

Because LioranDB V2 is still pre-alpha.

I'd rather onboard a smaller number of applications and understand exactly how they're using the database than throw open a giant "Buy Now" button and pretend the product has already reached cloud-database maturity.

Working with early users also gives us something benchmarks can't provide: real workloads.

Different applications create very different database pressure.

A CRM might perform huge numbers of indexed lookups.

A SaaS product might have strongly tenant-oriented access patterns.

An API might perform thousands of tiny reads.

Another application might continuously ingest data.

Those workloads expose problems synthetic benchmarks simply won't.

And because managed customers have direct founder support, if something strange happens, you're talking directly to the person building the database rather than bouncing through three support tiers.

What Is LioranDB?

LioranDB V2 is a document database developed in Rust with a MongoDB-style developer experience.

Its current architecture includes:

Application
     ↓
LioranDB Query Layer
     ↓
Transactions + MVCC
     ↓
B+Tree Primary Storage
     ↓
WAL + Checkpoints
     ↓
Page Cache
     ↓
Persistent Storage

     + Secondary LSM Indexes
     + Inverted Text Index

V2 pre-alpha launched on August 16, 2026, and development is currently moving toward the Alpha release planned for October 23, 2026.

The database is still under active development and is not currently presented as production-ready.

That's also why I'm particularly interested in working with developers who are willing to test it, push it, report weird behavior, and tell me where the developer experience sucks.

Interested?

You can learn about LioranDB on liorandb.com, or apply for a managed deployment through app.liorandb.com.

If you're building an early-stage SaaS, CRM, API, internal tool, or another backend-heavy product and want to experiment with LioranDB, I'd particularly like to hear about your workload.

And yes, trying to break the database is still encouraged.

LioranDB V2 Is in Pre-Alpha. Please Try to Break It.

Swaraj Puppalwar — Sat, 29 Aug 2026 19:39:12 +0000

LioranDB V2 is now publicly available in pre-alpha, and I want developers to do something slightly unusual:

Try to break it.

Not just install it, run insertOne(), see that it works, and close the terminal.

Push it.

Give it weird queries. Throw large datasets at it. Create indexes. Delete things. Restart the server. Send concurrent requests. Test edge cases. Try workflows I probably didn't think about.

If something behaves strangely, becomes painfully slow, crashes, returns an unexpected result, or simply feels bad to use, I want to know.

What is LioranDB?

LioranDB is a developer-first document database being developed in India.

V2 is written in Rust and currently includes things such as:

B+ Tree primary storage
MVCC
Write-Ahead Logging
Checkpoints and crash recovery
Secondary indexes
Full-text indexing
Docker deployment
TypeScript/JavaScript driver
MongoDB-style document APIs

The goal isn't to pretend that a pre-alpha database is already production-ready.

The goal is to find everything that's wrong with it before it gets there.

So, I'm Looking for Feedback

I'm especially interested in hearing about:

🐛 Bugs

Anything that crashes, hangs, produces incorrect results, corrupts state, or behaves differently from what you'd expect.

⚡ Performance problems

Slow queries, unexpected latency, bad scaling with larger collections, inefficient indexes, memory problems, or operations that become suspiciously expensive.

🧪 Edge cases

Strange documents. Strange queries. Strange sequences of operations.

Basically, be creative.

Databases tend to behave nicely until somebody does something the database author never imagined.

Be that somebody.

🧑‍💻 Developer experience

I'd also love feedback about the API itself.

Is something confusing?

Does an error message suck?

Is an operation unnecessarily complicated?

Did you have to read the documentation three times to understand something?

That's a bug too, just wearing nicer clothes.

How to Test It

Start here:

Documentation:
https://docs.liorandb.com

LioranDB:
https://liorandb.com

The documentation contains the setup instructions and APIs needed to start experimenting with LioranDB.

You don't need to build a serious application.

Create a test project, generate some data, connect the driver, and start attacking it.

Try things like:

thousands or millions of documents
concurrent reads and writes
secondary indexes
text search
pagination
large limit() values
unusual filters
sorting
aggregations
repeated updates and deletes
restarting LioranDB during workloads
crash/recovery scenarios
combinations of operations that look suspicious

If you manage to make LioranDB unhappy, congratulations.

That's exactly what I'm looking for.

Found Something?

Send me what happened at:

feedback@liorandb.com

If possible, include:

what you were trying to do
the query/code you ran
what you expected
what actually happened
dataset size
logs or error messages
your OS/environment
reproduction steps

Even if you're unsure whether something is technically a bug, send it.

Performance observations, confusing APIs, documentation problems, missing features, architectural criticism, and general feedback are all useful.

Why I'm Doing This

A database isn't validated because its benchmark graph looks pretty.

It's validated when people outside the project start doing things the original developer didn't anticipate.

LioranDB V2 is still pre-alpha.

There are going to be bugs.

There are going to be slow paths.

There are probably wonderfully cursed combinations of operations waiting somewhere in the engine.

I'd rather developers discover them now than users discover them later.

So install LioranDB.

Build something stupid with it.

Stress it.

Abuse the API.

And please, try to break my database.

https://liorandb.com

https://docs.liorandb.com

Feedback: feedback@liorandb.com

Swaraj's High Rise in Computers! | Nagpur Post | 23 May 2023

Swaraj Puppalwar — Mon, 24 Aug 2026 15:14:50 +0000

On Tuesday, 23 May 2023, Nagpur Post published an English feature about my early journey into computers and programming.

The article was titled “Swaraj's high rise in computers!” with the subheading “Developed many computer programs at an early age.”

I was 15 years old when the article was published.

I had started programming at the age of 11 and was primarily self-taught, learning through books, online tutorials, platforms such as Udemy and YouTube, and, most importantly, building projects.

By that point, I had experimented with software, Android applications, websites and games.

Some of my early projects included Productive Pay, a productivity tool for Python developers, a calculation-speed improvement tool for mathematics practice, and applications built while experimenting with multiple programming languages.

My early technology stack included Python, Java, C/C++, HTML, CSS, JavaScript and Node.js.

The newspaper also covered some of my participation and achievements in computer science and academic competitions, including cyber, computer and mathematics olympiads and the National Children's Science Congress.

Reading the article again years later feels almost like opening an old Git commit.

The codebase has changed considerably.

What started as curiosity about programming eventually grew into an interest in full-stack development, backend engineering, databases and developer infrastructure.

Today, I am building LioranDB and working toward a much larger goal: building developer infrastructure from India.

I am preserving this article here because it captures one of the earliest public records of that journey, from a time when I was simply a school student fascinated by what could be built with a computer and some code.

Publication: Nagpur Post
Location: Nagpur
Date: Tuesday, 23 May 2023
Original Headline: Swaraj's high rise in computers!
Subheading: Developed many computer programs at an early age

स्वराजची संगणक क्षेत्रात उंच भरारी | Navarashtra, Chandrapur | 23 May 2023

Swaraj Puppalwar — Mon, 24 Aug 2026 15:14:10 +0000

On 23 May 2023, Navarashtra featured my early journey in computer science and programming in its Chandrapur edition.

The article was published under the Marathi headline “स्वराजची संगणक क्षेत्रात उंच भरारी” on Page 4.

I was 15 years old at the time.

My journey into programming had started several years earlier, when I began learning to code at the age of 11. Instead of limiting that learning to tutorials, I became interested in actually building things.

Over the following years, I experimented with software, Android applications, websites, games and programming projects while continuing to learn different technologies.

The Navarashtra article documented this early phase of my journey and highlighted both my programming work and participation in technology and academic competitions.

Some of the technologies I explored during those years included Python, Java, C/C++, HTML, CSS, JavaScript and Node.js.

What I find interesting about looking at this article years later is how much the scale of the problems I want to solve has changed.

The 15-year-old version of me was excited about making applications and experimenting with code.

Today, I spend much of my time thinking about storage engines, databases, Rust, backend architecture and developer infrastructure.

Those are very different engineering problems, but they came from the same curiosity.

This clipping is therefore more than a newspaper mention for me. It is a snapshot of where the journey was in May 2023, long before I knew where that curiosity would eventually lead.

Publication: Navarashtra
Edition: Chandrapur
Date: 23 May 2023
Page: 4
Original Marathi Headline: स्वराजची संगणक क्षेत्रात उंच भरारी

‘स्वराज’ची संगणकात गगनभरारी | Tarun Bharat, Purva Vidarbha | 29 May 2023

Swaraj Puppalwar — Mon, 24 Aug 2026 15:13:30 +0000

On 29 May 2023, Tarun Bharat featured my journey in technology and programming in its Purva Vidarbha edition.

The Marathi article, titled “‘स्वराज’ची संगणकात गगनभरारी”, appeared on Page 2 of the newspaper.

At the time, I was 15 years old and had already spent several years exploring programming and computer science. I started programming at the age of 11, largely learning through experimentation, books, online resources and building projects of my own.

The article covered my early journey in software development, including my work with programming languages and technologies such as Python, Java, C/C++, HTML, CSS, JavaScript and Node.js.

It also highlighted some of the projects I had built while learning programming, along with my participation and achievements in computer science, cyber and mathematics competitions.

Looking back from 2026, this newspaper clipping represents a very different stage of my journey.

Back then, I was a school student experimenting with software because I genuinely enjoyed understanding how computers worked.

Today, that curiosity has evolved into working on databases, backend systems and developer infrastructure, including building LioranDB.

The technology has changed. The projects have become much larger. But the habit that started everything remains the same: learn something, build something, break it, understand it, and build again.

Publication: Tarun Bharat
Edition: Purva Vidarbha
Date: 29 May 2023
Page: 2
Original Marathi Headline: ‘स्वराज’ची संगणकात गगनभरारी

LioranDB TypeScript Series #12: Production Patterns, Error Handling and What Comes Next

Swaraj Puppalwar — Sat, 15 Aug 2026 20:16:34 +0000

LioranDB TypeScript Series #12: Production Patterns, Error Handling and What Comes Next

LioranDB TypeScript Series: Build with a developer-first document database powered by Rust and designed for TypeScript.

We started this series with:

docker run ...

Eleven articles later, we've covered application queries, indexes, authentication, operations, backups, the CLI and managed deployment.

Let's finish with the things that matter when your application stops being a demo.

Understand driver errors

The LioranDB TypeScript driver exports a structured error hierarchy.

General errors include:

LioranDriverError
ApiError
AuthError
NetworkError
TimeoutError
ConfigurationError
SerializationError

Authentication-related errors include:

AuthenticationError
AuthorizationError
PasswordChangeRequiredError
SessionExpiredError

Lifecycle errors include:

ClientClosedError
CursorClosedError
CursorInitializedError

Server-side conditions include errors such as:

ConflictError
DuplicateKeyError
NotFoundError
ServerNotReadyError
ServerOverloadedError
ServerUnavailableError
ValidationError

Use `instanceof`

Don't parse human-readable error messages.

import {
  DuplicateKeyError,
  TimeoutError,
} from "@liorandb/driver";

try {
  await users.insertOne(user);
} catch (error) {
  if (error instanceof DuplicateKeyError) {
    // Handle duplicate data.
  }

  if (error instanceof TimeoutError) {
    // Apply your timeout/retry policy.
  }

  throw error;
}

The driver also exports error and warning code constants for applications that need structured classification.

Add diagnostics

Attach your application's trace identifier:

client.setDiagnosticHeaders({
  "x-trace-id": traceId,
});

Observe operations:

client.setResponseObserver((event) => {
  console.log({
    transport: event.transport,
    operation: event.operation,
    durationMS: event.durationMS,
    requestId: event.requestId,
  });
});

And surface slow operations:

const client = await LioranDBClient.connect(uri, {
  slowRequestThresholdMS: 200,

  onWarning(warning) {
    console.warn(
      warning.code,
      warning.message
    );
  },
});

Production checklist

Before calling a deployment production-ready:

URL-encode credentials inside connection strings.
Rotate bootstrap credentials immediately.
Use application-specific users and roles.
Prefer least-privilege permissions.
Use typed collections.
Use idempotency keys where retry safety matters.
Configure appropriate request timeouts.
Poll backup and restore jobs until terminal state.
Verify backups.
Monitor health, readiness and metrics.
Keep database ports private.
Put TLS at the public edge.
Close clients and cursors cleanly.
Handle structured driver errors rather than parsing strings.

Remember: this is pre-alpha

LioranDB V2 launched its pre-alpha on 16 August 2026.

That word matters.

Pre-alpha is where APIs can evolve, edge cases get discovered and real workloads expose assumptions that benchmarks don't.

If you're experimenting with it today, feedback is extremely valuable.

What comes next?

The current target for the LioranDB V2 alpha is:

23 October 2026

Work toward alpha includes areas such as:

production hardening
larger dataset testing
richer aggregation capabilities
clustering improvements
deployment tooling
managed infrastructure
developer experience improvements

The direction remains the same:

Build developer infrastructure from India that developers can actually use.

Start building

Install the driver:

npm install @liorandb/driver@2.0.6

Install the CLI:

npm install -g @liorandb/cli@1.0.6

Run the database:

docker pull liorandb/liorandb:pre-alpha

Resources

LioranDB: https://liorandb.com
Documentation: https://docs.liorandb.com
Driver: @liorandb/driver@2.0.5
CLI: @liorandb/cli@1.0.5

LioranDB is created by Swaraj Puppalwar, Founder & CTO at Lioran Developer Solutions.

GitHub: https://github.com/UltronTheAI
Lioran Developer Solutions: https://lioransolutions.com

Previous: Part 11 → Docker Compose, Caddy & TLS

That's the end of the LioranDB TypeScript Series.

Now comes the fun part:

Build something with it, stress it, benchmark it, find the weird edge cases and tell us what you discover.

Pre-alpha gets better when developers actually try to break it. 💗

LioranDB TypeScript Series #11: Deploy LioranDB with Docker Compose, Caddy and TLS

Swaraj Puppalwar — Sat, 15 Aug 2026 20:14:45 +0000

LioranDB TypeScript Series #11: Deploy LioranDB with Docker Compose, Caddy and TLS

LioranDB TypeScript Series: Build with a developer-first document database powered by Rust and designed for TypeScript.

Running LioranDB locally is easy.

Exposing a database server to the internet deserves considerably more care.

Let's build a cleaner managed deployment.

Architecture

Instead of publishing every LioranDB port:

Internet
   ↓
HTTPS / TLS
   ↓
Caddy
   ↓
Docker network
   ↓
LioranDB

Only the reverse proxy should be publicly reachable.

Example Caddy configuration

acme.db.example.com {
  reverse_proxy liorandb:27018
}

acme.grpc.example.com {
  reverse_proxy h2c://liorandb:27019
}

Caddy handles the public TLS edge while LioranDB remains inside the Docker network.

Docker Compose

services:
  liorandb:
    image: liorandb/liorandb:pre-alpha
    container_name: liorandb-acme
    restart: unless-stopped

    cpus: 2.0
    mem_limit: 3.5g

    environment:
      LIORANDB_TLS_MODE: insecure
      LIORANDB_GRPC_BIND_ADDR: 0.0.0.0:27019
      LIORANDB_METRICS_ADDR: 0.0.0.0:27201

      LIORANDB_ADVERTISED_HTTP_ADDR: acme.db.example.com:443
      LIORANDB_ADVERTISED_GRPC_ADDR: acme.grpc.example.com:443

      LIORANDB_BOOTSTRAP_PASSWORD_FILE: /run/liorandb/bootstrap-password.txt

    expose:
      - "27018"
      - "27019"
      - "27201"

    volumes:
      - liorandb-data:/var/lib/liorandb/data
      - ./bootstrap-password.txt:/run/liorandb/bootstrap-password.txt:ro

    networks:
      - public-edge
      - metrics-private

  caddy:
    image: caddy:2
    restart: unless-stopped

    ports:
      - "80:80"
      - "443:443"

    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro

    networks:
      - public-edge

volumes:
  liorandb-data:

networks:
  public-edge:

  metrics-private:
    internal: true

Notice what's missing

There is no:

ports:
  - "27018:27018"
  - "27019:27019"
  - "27201:27201"

on the LioranDB service.

That's deliberate.

expose makes the ports available to services on the Docker network without publishing them directly on the host.

Firewall

For a typical Ubuntu deployment, the public firewall should only need the services you intentionally expose, such as:

22   SSH
80   HTTP
443  HTTPS

Don't casually expose:

27018
27019
27201

to the public internet.

Bootstrap password file

Generate a strong secret:

openssl rand -base64 32

Store it in:

bootstrap-password.txt

Then restrict access:

chmod 600 bootstrap-password.txt

The container receives it as a read-only mounted file.

Deployment flow

Validate your Compose configuration:

docker compose config

Start everything:

docker compose up -d

Inspect:

docker compose ps

Then verify health/readiness and advertised endpoints before connecting application traffic.

Application connection

Your application can then connect through the public TLS endpoint:

liorandb://admin:<encoded-password>@acme.db.example.com:443/default

Remember to URL-encode the password.

The important boundary

The database is not your public web server.

Treat the reverse proxy as the edge and keep the database itself on the private network.

That one architectural decision removes an impressive collection of future headaches.

Resources

Managed Deployment Guide:
https://docs.liorandb.com/docs/deployment/managed

Documentation: https://docs.liorandb.com
Website: https://liorandb.com

Previous: Part 10 → Official CLI
Next: Part 12 → Production Patterns, Diagnostics & What's Next

LioranDB TypeScript Series #10: Mastering the Official LioranDB CLI

Swaraj Puppalwar — Sat, 15 Aug 2026 20:13:15 +0000

LioranDB TypeScript Series #10: Mastering the Official LioranDB CLI

LioranDB TypeScript Series: Build with a developer-first document database powered by Rust and designed for TypeScript.

Not everything needs a dashboard.

Sometimes you just want a terminal and a database that listens.

Meet the official LioranDB CLI.

Install

npm install -g @liorandb/cli@1.0.5

The executable is:

liorandb

Initialize

liorandb init

Configure a connection:

liorandb set url \
  "liorandb://admin:YOUR_PASSWORD@127.0.0.1:27018/default"

Authenticate:

printf '%s' "$LIORANDB_PASSWORD" |
liorandb login admin --password-stdin

Select a database

liorandb db use default

Create a collection:

liorandb collection create products

Insert from stdin

printf '{"sku":"bk-001","title":"Blue Notebook","active":true}' |
liorandb insert-one products --stdin

Count:

liorandb count products

Then jump into the interactive shell:

liorandb shell

Profiles

The CLI supports local profiles, which makes switching environments much less painful.

Think:

local
staging
production
client-a
client-b

instead of repeatedly pasting connection information.

Output formats

Automation doesn't want pretty tables.

Humans often do.

The CLI supports output modes including:

table
json
ndjson
quiet

Global flags include:

--profile
--url
--output
--json
--quiet
--no-color
--debug

What can the CLI control?

Quite a lot.

Data

db
collection
find
find-one
insert-one
update-one
delete-many
aggregate
count

Indexes

index list
index create
index create-text
index drop

Authentication

login
logout
whoami
sessions
change-password

Administration

user
role
settings
cors

Operations

status
health
doctor
metrics
cluster
backup

Safety

Destructive commands should be difficult to trigger accidentally.

Operations such as drops, broad deletions and backup restore/delete flows use confirmation mechanisms unless explicitly overridden where supported.

That's intentional.

A CLI should help you operate the database, not speedrun deleting Tuesday.

Local state

CLI state is stored under:

.liorandb/state

You can override the location with:

LIORANDB_STATE_DIR

Passwords are not persisted as ordinary stored profile values.

CLI + Driver

The CLI and TypeScript driver aren't competing interfaces.

A common setup is:

Application code
    → @liorandb/driver

Developers / CI / Operations
    → @liorandb/cli

Use each where it fits best.

Resources

CLI Documentation:
https://docs.liorandb.com/docs/cli/overview

Documentation: https://docs.liorandb.com
Website: https://liorandb.com

Previous: Part 9 → Operations & Backups
Next: Part 11 → Docker Compose, Caddy & TLS

DEV Community: Swaraj Puppalwar

Prompt Engineering for Non‑Tech Professionals: Mental Models and Practical Workflows

Introduction

1. The Prompt as a Conversation Blueprint

2. The Core Prompt Design Framework

Quick Template

3. Diagnostic Checklist – Is Your Prompt Ready?

4. Prompt Strategies Compared

5. Hands‑On Workflow for a Real‑World Scenario

6. Prompting Visual AI – From Text to Image

7. Embedding Prompts in Team Workflows

8. Responsible Prompt Engineering

9. Measuring Prompt Success

Conclusion

Building a Sustainable Micro‑Garden in a City Apartment: Core Models and Actionable Checklists

Introduction

1. The Site‑First Mental Model

Site Diagnosis Checklist

2. Space‑Efficiency Framework

Quick Layout Exercise

3. Water Management & Closed‑Loop Metrics

Starter Water System (DIY)

4. Plant Selection & 12‑Week Succession Calendar

12‑Week Action Plan (Example for a 1‑m² Balcony)

5. Integrated Pest Management (IPM) for Small Spaces

Quick IPM Checklist

6. Harvest, Post‑Harvest, and Storage Hacks

7. Building Community and Scaling Impact

Conclusion

Designing Trust‑Centric Culture in Remote Teams: Frameworks You Can Deploy Today

Why Remote Culture Needs a Blueprint

1. The Culture Map – A Visual Audit Tool

What It Is

How to Build One

Immediate Takeaway

2. Trust‑Building Matrix – Codifying Psychological Safety

Using the Matrix

3. Ritual‑Design Canvas – Engineering Sustainable Routines

Quick Workflow

Avoiding Ritual Fatigue

4. Tool Selection Decision Tree – Aligning Tech with Values

Implementation Checklist

5. Culture Scorecard – Measuring What Matters

Running a Culture Sprint

6. Putting It All Together – A 30‑Day Launch Plan

Conclusion

Meet LioranDB: A Document Database Built in Rust

Meet LioranDB: A Document Database Built in Rust

What Is LioranDB?

Why Build Another Database?

LioranDB V2 Is Still Pre-Alpha

Current Performance Target

Watch the Video

Try LioranDB

LioranDB Managed Hosting Is Now Open: ₹5,000/Month for Early-Stage Startups

Two Pricing Options

1. Fixed Plan: ₹5,000/month

2. Custom Plan

How Do You Get a Managed LioranDB Database?

Why an Application Process?

What Is LioranDB?

Interested?

LioranDB V2 Is in Pre-Alpha. Please Try to Break It.

What is LioranDB?

So, I'm Looking for Feedback

How to Test It

Found Something?

Why I'm Doing This

Swaraj's High Rise in Computers! | Nagpur Post | 23 May 2023

स्वराजची संगणक क्षेत्रात उंच भरारी | Navarashtra, Chandrapur | 23 May 2023

‘स्वराज’ची संगणकात गगनभरारी | Tarun Bharat, Purva Vidarbha | 29 May 2023

LioranDB TypeScript Series #12: Production Patterns, Error Handling and What Comes Next

LioranDB TypeScript Series #12: Production Patterns, Error Handling and What Comes Next

Understand driver errors

Use instanceof

Add diagnostics

Production checklist

Remember: this is pre-alpha

What comes next?

Start building

Use `instanceof`