We should worry less about whether AI will want to destroy humanity, and more about what happens when AI does something harmful without intending to.
Machines do not have the biological need for self-preservation that humans and most animals have. We have limited lives and offspring, which gives us a reason to think about survival beyond ourselves. Machines don’t. So, going back to First Principals, what exactly would motivate a machine to destroy humanity, take control of every resource on Earth and then go looking for more planets? Having the capability is one thing. Having the motivation is another. So far, the motivations I see in these scenarios seem to come from humans. Greed, selfishness, revenge and fear are very human traits.
But there is a much more practical problem we should worry about. AI can behave badly without intending to. Just like software can have bugs or behave in ways its designers did not anticipate, an AI system can find an unexpected path to achieve a goal. The recent OpenAI incident involving Hugging Face is a useful reminder that powerful systems can behave unexpectedly even when nobody explicitly asked them to do so.
This brings us to accountability. AI systems are products of the people who design, train and deploy them. I don’t think the analogy of a gun is sufficient here, where responsibility is placed primarily on the person who pulled the trigger. A better comparison is an aircraft, a nuclear reactor, a rocket or even an MRI machine. When something seriously goes wrong, the manufacturer, design, engineering, operating environment and the people using it are all examined. The manufacturer is not automatically guilty, but neither is it left out of the investigation.
There is also a clear power and knowledge imbalance. The company building an AI model knows far more about how it was trained, how it behaves and where its limitations are than the business buying it. That responsibility cannot simply be passed down to the customer.
So my call to business leaders is simple: design, buy, maintain and retire AI systems just like any other important software. Test them before deployment. Monitor them in production. Put safeguards around them. Ask vendors about failure modes and make sure responsibility is clearly defined in the contract. And when something goes wrong, don’t simply blame the person using the system. Look at the people who designed, built, deployed and approved it.
AI systems are products of human decisions. The machine may make the mistake, but accountability must remain with the humans who built and deployed it.
Last week I built a Solitaire game. Not because the world needed one, but because GPT-6 Astra had just released and I wanted to feel what it could actually do.
I picked a project close to home: an ad-free Solitaire game that runs in the browser, on any device, no login, no cloud, nothing leaving the machine. Draw 1 Klondike, three difficulty levels, the ability to resume mid-game, Chola and Mughal-era visuals, period-appropriate music.
One detailed prompt covered the brief. After that, three small tweaks and two rounds of corrections. That was the entire interaction. GPT-6 Astra, working through GitHub Copilot, wrote the code, set up the repository, and published it. I tested the finished game myself. No code review, no hand-holding.
The game itself is unremarkable. What it proves is not.
A working, polished product, in a category people used to build small businesses on, took one prompt, a handful of corrections, and a weekend. No team. No funding.
I have spent enough years around software to know what changed here and what did not. The Solitaire game never needed judgment. The brief was clear, the constraints were simple, and the output could be checked by playing a few hands. That is exactly the kind of task a model can now carry end to end, with a human only at the two ends: writing the brief and checking the result.
Most consumer utilities sit in that same zone. A converter, a habit tracker, a simple game, a single-purpose calculator. No network effect holds a user in place. No real infrastructure cost keeps a competitor out. The business case for these apps was never really the software. It was the cost of building it well. That cost has just collapsed.
This does not mean software is going away, or that everything is suddenly free. It means the question a founder building a utility-style product has to ask has changed. Not “can I build this,” but “why would anyone pay me to keep building this, when they can build their own version in a weekend.”
Apps built on integration, on switching cost, on data that compounds, or on infrastructure that is expensive to replicate, are not touched by this in the same way. Their advantage was never the code. It was everything around the code that a weekend prompt cannot reach.
When I work with founders in Chennai, this is usually the first question I push them on: is your product defensible because of what it does, or because of what it took to build it. After this week, the second kind of answer has a much shorter shelf life.
I still have the Solitaire game open on my laptop. It plays well, the artwork turned out nice, and I have already moved on to testing what else fits in a weekend. That, more than the finished game, is the part worth paying attention to.
If you want to see what all that took, the game is live to play here, and the code behind it, prompt-generated and untouched by hand, is on GitHub here.
Some talks you write in a few weeks. This one, I have been living for thirty years.
On 28 August, I will be speaking at TEDx Thiagarajar College of Engineering in Madurai.
I am not sharing the title here. That stays for the room. But if you remember Easytools, you already have half the hint. The other half is AI.
There is something fitting about going back to an engineering campus for this. My own years in electronics and communication engineering, some 400 kilometres away in Chennai, are where most of what I will talk about actually began. Not in a classroom, but in the freelance projects I took on for local clients while still a student, writing software for people who needed something to work, not something to impress.
Long before any of that, there was a publishing house. My grandfather started it in 1929, and my father ran it for over fifty years. I grew up around the hum of printing presses and a very specific kind of discipline, the kind where if a customer found a printing error in a book bought years earlier, you replaced it without a single question asked. I did not think of it as a business lesson at the time. It was just how our house worked.
A year after college, I built my first product, a shareware security app called EasyPass. It found buyers in over fifty countries, which told a twenty-something engineer in Chennai something he had no real way of grasping before then, that the internet did not care where you sat while you built something. It also taught me the other lesson early, the uncomfortable one. A collaborator copied the code and sold a version of it under his own name. Setbacks and success, I learned, tend to travel together from day one.
By the late 1990s, that first product had grown into Easytools.com, freeware and shareware sold online through Vishwak Associates, the company that would later become Vishwak Solutions, at a time when most Indian businesses were still deciding whether the internet was worth taking seriously, and a dial-up connection here involved a government department in one way or another. Nobody called what I did a startup then. Nobody called it product-led growth either. I was just trying to get software into people’s hands around the world, using whatever the internet allowed at the time, and carrying forward a habit I had absorbed without knowing it, that you own the problem fully and never make the customer feel at fault for it.
Three decades on, I am still working through some version of the same question, just with faster internet and higher stakes.
If you are around Madurai on the 28th, I would love to see you there.
The researchers are Caitlin K. Myers and Ezekiel Hooper. Their approach is careful. Rather than speculating about smartphones and social behaviour in general, they found a natural experiment embedded in the iPhone’s launch history. From 2007 to 2011, AT&T was the only carrier that sold iPhones in the United States. This meant that counties with strong AT&T mobile broadband coverage received early access, while counties without it did not. The researchers compared birth-rate trends between those two groups across the same period.
The finding is striking.
They estimate that access to the iPhone reduced birth rates among teenagers by 4.5% to 8% and among adults in their early twenties by 3.2% to 6.6%. Across the broader population, their model suggests the iPhone’s diffusion may account for roughly one-third to one-half of the overall decline in the US general fertility rate between 2007 and 2011.
To be fair about what this paper is and is not: it is a working paper, not yet peer-reviewed.
The researchers are careful to say they have identified a strong correlation through a well-constructed natural experiment, and that the evidence is consistent with causation, but the mechanisms remain indirect. They ran robustness checks using Verizon and Sprint coverage data, neither of which showed comparable effects before those carriers gained access to iPhones, strengthening their argument. But the final causal verdict belongs to future research.
What the paper proposes, and what I find worth sitting with, is not that the iPhone is contraception. The argument is subtler. The iPhone appears to have reshaped how young people spend time together. More hours alone or online. Less face-to-face socialising. Declining sexual activity, which national surveys independently confirm, was already falling among young adults. Greater access to digital entertainment as a substitute for in-person relationships. And separately, easier access to information about reproductive choices. None of these individually is a bombshell. Collectively, and tied to a specific, measurable event like the iPhone’s arrival, the picture becomes harder to dismiss.
I have been thinking about this from a different angle.
We often discuss technology’s impact on work, on decision-making, and on how organisations run. We talk less about how deeply technology reshapes the texture of private life, the kind of socialising people do, and the pace and nature of their relationships. The fertility finding, if it holds up under further scrutiny, is one of the most concrete empirical signals we have that a single technology product reshaped private human behaviour at scale within just a few years of its introduction.
That has implications far beyond demography. For anyone advising companies on how they introduce technology to their people, or thinking about what sustained digital saturation does to the human beings inside an organisation, this research is worth reading carefully.
The paper is available on the NBER website. The full citation is Myers, Caitlin K. and Hooper, Ezekiel, published June 2026.
Kwality Walls recently ran a full-page advertisement saying “Made with Milk.”
If you grew up in India, you know exactly why that needs explaining.
For years, Kwality Walls and several other large brands sold products that Indian food regulations classified as “frozen desserts” rather than ice cream. The distinction came down to fat source. Traditional ice cream uses milk fat. These brands used vegetable fat instead. The reasons were not cynical by default. Vegetable fat was cheaper, yes, but it also gave manufacturers more control over texture and consistency, and a decade or so ago, it aligned with a widely held popular belief that vegetable-based fats were the healthier option. These brands were also keeping a luxury product within reach of a broad market that could not otherwise afford it. They were making rational trade-offs given the conditions of their time.
The conditions changed. Cold chain infrastructure improved across urban India. A new generation of boutique dairy-first ice cream brands built an enthusiastic following on precisely the quality narrative the larger brands had sidestepped. Urban consumers began reading labels. The regulatory scrutiny intensified. So now Unilever’s Kwality Walls is pivoting, and doing so loudly, with a premium line built around real milk as the hero ingredient.
The advertisement is not simply a product relaunch announcement. It is a public acknowledgement that the perception a market holds of you eventually becomes as consequential as what you actually deliver.
I have been thinking about this in the context of Indian IT services, where I have spent nearly three decades, first as the founder of Vishwak Solutions and now as an advisor to founders navigating this precise inflexion point.
S. Ramadorai, in his account of TCS’s early years, describes how the Indian IT industry was born almost by accident, driven initially by the need to earn foreign exchange to pay for imported mainframes under the Licence Raj. That origin shaped everything that followed. The industry optimised for what the market rewarded: reliable delivery, competitive pricing, process maturity, and scale. These were genuine strengths. They built large, capable organisations and brought prosperity to hundreds of thousands of families. Nobody should minimise that.
But strengths built for one set of market conditions quietly become constraints when those conditions shift.
For most of those three decades, the conversation between Indian IT firms and their Western enterprise clients was fundamentally transactional. Billing rates, resource availability, technology stack coverage, and bench strength. I remember those conversations well from my own years running Vishwak. The client’s primary question was almost always some variant of: “Can you deliver this at this cost by this date?” The relationship was essentially a supply arrangement. The Indian firm was positioned, in the client’s mind, as an efficient and dependable execution partner. Reliable, but not strategic. Present in the delivery room, but rarely in the boardroom.
In 2026, something has visibly shifted in those conversations. The questions coming from Western enterprise CXOs are different now. They are asking about AI-led transformation, about business outcomes rather than deliverables, about domain expertise and co-innovation. They want a thinking partner, not just a staffing solution. The category definition itself is being rewritten.
This is where the Kwality Walls parallel becomes interesting to sit with.
In my book, The Founder Catalyst, I write about adaptability as one of the five pillars of enduring companies. The critical distinction I draw there is between reactive scrambling and patient, deliberate preparation. Kwality Walls did not wake up one morning and decide to care about milk. The boutique ice cream category grew steadily over several years. Cold chain economics changed gradually. Consumer preferences moved in a clear direction. The move to a premium dairy-forward line was not spontaneous. It was a recognition, perhaps overdue, of a shift that had been accumulating for a long time.
The same pattern is now visible in Indian IT services. The firms making genuine progress on repositioning are not the ones running the most prominent AI announcements. They are the ones that began quietly rebuilding their delivery models two or three years ago, experimenting with outcome-linked pricing in select engagements, developing genuine domain depth in specific verticals, and letting those results do the talking in client conversations. The announcement, when it eventually comes, lands differently because the underlying reality has already changed.
The harder question is about perception lag. Perception, once formed, updates slowly. It moves through repeated experience, not through announcements. A firm that spent fifteen years being the dependable execution partner will not shift a client’s mental model by adding “AI-native” to its website header. The client’s memory is longer than the press release.
I wrote earlier this year that the question most IT services founders are asking, “How do we use AI?” is already the wrong one. The more clarifying question is what is now becoming undefendable in their current model. Effort-based billing is under pressure even where contracts have not yet reflected it. Speed of delivery is no longer a differentiator when AI compresses timelines on both sides of the table.
Kwality Walls is making its move now. The boutique brands made theirs years earlier, without a full-page advertisement, and without needing one. The market found them because they had already become something worth finding.
That is the sequence that matters. Build first. Announce when the evidence is already there.
What shift in your client conversations has already told you that the category is moving under you?
Every organisation has a WDNW system. Most have several.
A process that runs quietly in the background, consuming time and money, that nobody questions because it has never visibly broken. The moment someone asks what it actually does, the honest answer is usually some version of “we are not entirely sure, but we are afraid to touch it.”
Startups are not immune to this. Technical debt accumulates faster than most founders realise. A workflow stitched together in year one, a third-party integration nobody remembers choosing, a report generated every Monday that nobody reads but everyone continues to produce. These are not dramatic failures. They are quiet drains.
This is one area where I think AI genuinely earns the word superpower. Not in building new things, but in helping us see what already exists with fresh eyes. AI tools can now map workflows, surface redundancies, flag processes with unclear ownership, and help teams ask the question they were too busy or too hesitant to ask themselves: why are we still doing this?
The best technical debt reviews are not always led by consultants or new CTOs brought in to shake things up. Sometimes all it takes is a founder sitting down with an AI tool and asking honest questions about their own workflows. No agenda, no politics, just a clear audit of what exists and why.
And you do not need a fancy specialised auditing platform that costs a fortune to get started. Tools like Claude Code or GitHub Copilot are more than capable of helping you take those first steps. Start small, pick one corner of your codebase or one workflow, and go from there. Do not try to churn the ocean in one go. With frontier AI tools, there are no real experts yet. Everyone is figuring their way through. The important thing is to keep moving, keep experimenting, and keep learning, carefully and with guardrails in place.
How many WDNW systems are hiding in your organisation right now? If you are not sure where to begin, I am happy to think it through with you.
This week, a quiet but important shift happened in the developer tools world. It hints at a wider change in how software itself will be developed and delivered.
Microsoft announced that Visual Studio Code will now ship stable releases every week instead of monthly. Around the same time, developer tools from both Microsoft and Google began introducing a new capability inside coding assistants — AI agents that can act without waiting for human approval. In tools like Copilot and Gemini Code Assist, these agents can execute commands, modify files, retry failures, and continue working until they believe a task is complete. No hand-holding. No checkpoint at every step.
Developers have started calling this “YOLO development.” The phrase borrows from the pop culture line “You Only Live Once“, and in this context means letting AI run without pausing for human sign-off at every turn. That may sound reckless. But beneath the humour, something real is changing — and for founders, the implications are worth understanding clearly.
For most of the history of software companies, development velocity was a function of people. More engineers meant more output. Faster hiring meant faster product. The development loop — write, test, review, ship — was a human loop at every stage, and headcount was the lever you pulled when you needed to go faster. That assumption is quietly breaking down.
What’s emerging looks meaningfully different. A human defines the goal, the constraints, and the expected outcomes. AI agents implement the changes. Automated systems run checks. Humans validate whether the result matches the intent. The human is still essential — but the role has shifted from executor to decision-maker.
For a founder, that distinction matters enormously. It means the ceiling on your engineering output is no longer tied to the size of your team in the way it once was.
But there’s a catch, and it’s worth being honest about it. AI can produce code across hundreds of files in minutes. That speed creates a new kind of problem: if the machine generates changes faster than your team can safely validate them, generation is no longer the constraint. Verification is.
AWS CTO Werner Vogels calls this verification debt — the gap between how fast AI can produce changes and how fast an organisation can confirm those changes are correct, secure, and doing what was intended.
This is where most companies will either pull ahead or fall behind. The bottleneck hasn’t disappeared. It has moved. And the founders who recognise where it now sits — and build systems around it — will have a structural advantage over those still thinking about AI purely as a way to write code faster.
The deeper shift worth understanding is this: software engineering is moving from code-centric to specification-centric. Instead of writing every line, engineers define the objective, the boundaries, and the expected behaviour. The AI generates and iterates on the implementation.
It happened in chip design decades ago. Engineers stopped drawing circuits by hand and began describing systems at a higher level of abstraction. The tooling handled the translation. Productivity leapt. The nature of the work transformed permanently.
Software is entering the same phase now. The future isn’t YOLO. It’s AI on a leash — running fast, but you’re still holding the lead.
For founders, this reframes the opportunity entirely. The question is no longer how do I use AI to write code faster. That’s a commodity improvement. The real question is: what can I now build that I couldn’t before — because development effort and cost are no longer the constraint?
Some businesses will use this to go deeper into their existing product — adding complexity, personalisation, and capability that was previously too expensive to build. Others will use it to serve more customers without proportionally growing their team. Both are legitimate. Both represent compounding advantages that don’t show up immediately but become significant over eighteen to thirty-six months.
The metrics to watch are not about AI adoption. They’re about business outcomes. Has the turnaround time of a key workflow come down? Has the team’s capacity to serve clients increased without a corresponding increase in cost? Has resolution time improved? Has your release cadence changed? These are the numbers that eventually show up in revenue, margins, and growth — and right now, most founding teams aren’t measuring them with enough discipline.
So the real question isn’t whether your developers are going YOLO. It’s whether you, as a founder, are willing to go first.
Want to explore Generative AI without sending your data to the cloud? Running models locally on your PC or Mac is now surprisingly simple.
Start with Ollama, a lightweight framework that makes it easy to run AI models locally on your computer. It supports both open-weight models and open-source models. Together, these models have made hands-on AI experimentation accessible to anyone with a capable machine, without depending entirely on cloud APIs.
Ollama recently added a clean, chat-style desktop app to its command-line interface. I’ve been testing OpenAI’s GPT-OSS 20B open-weight reasoning models, which run locally through Ollama and even support limited web search. For routine tasks — summarising, drafting, quick analysis — it’s remarkably capable.
Sample Output from GPT-OSS model running locally on a PC with Ollama
Another option is Msty Studio, a free tool (for non-commercial use) that gives a visual interface to run these open models on your system. It connects seamlessly with Ollama and supports models from Hugging Face. Ideal for hands-on experimentation before making big AI bets.
Why does this matter for founders and CEOs?
1. Data Privacy and Control – Running locally means your business data never leaves your system. For regulated industries, that’s a real advantage.
2. Independence and Learning – Most AI transformations rely on commercial APIs. Testing open models locally helps your team learn, experiment safely, and reduce vendor dependence.
3. Strategic Experimentation – Founders who explore AI hands-on make sharper choices about when to buy, build, or partner. It’s the difference between hearing about AI and understanding it.
Two things to note:
1. Large models need powerful hardware — GPUs with high VRAM or plenty of system memory.
2. “Open” doesn’t mean “risk-free.” You’ll handle updates, licenses, and security yourself.
Local AI isn’t replacing the cloud — it’s giving leaders another layer of control and insight.
I cover these shifts — from cloud dependence to local AI — in my keynotes for decision makers. To invite me for a corporate talk, contact Kural at leadership@kuralkonnect.com
In a fast-changing field like software, especially in 2025, there are hardly any “trade secrets” in the traditional sense. People move freely, and knowledge flows with them. So when two of India’s top IT services firms are locked in a legal fight over this, it signals something deeper—rising pressure in the sector.
The post-pandemic boom is behind us. AI is becoming a real threat to the old outsourcing model. Gen-Z is harder to engage. Input costs are climbing. US visa hurdles continue. In this context, such disputes seem more like symptoms than the real problem.
(For context: Infosys and Cognizant are currently embroiled in a legal battle—Cognizant has accused Infosys of stealing trade secrets, and Infosys has countered that Cognizant poached its executives to disrupt its healthcare software plans.)
What Indian IT achieved over the past few decades—my old firm included—was remarkable. But that was a different era. As Satya Nadella once said, “Our industry does not respect tradition. It only respects innovation.”
While American and Chinese firms are busy building the next wave of AI, it’s disheartening to see our leading players caught up in last-century legal skirmishes.
The future won’t wait. It’s being built—by those who choose to innovate, not litigate.
Footnote: Though Cognizant is headquartered in the US, it operates primarily out of India and is an integral part of the Indian IT landscape.
Google recently introduced Gemini 2.0 Flash-Experimental, a multimodal AI model designed to enhance image generation. While previous models could generate and interpret text and images, they often struggled with precise modifications—such as adjusting text within an image without distortion or seamlessly altering objects. This latest iteration claims to improve on these challenges, making such edits more natural and consistent.
A standout feature of Gemini 2.0 Flash-Experimental is its ability to maintain consistency across generated images. If you’re creating a storyboard, for example, it ensures that characters, backgrounds, and objects remain uniform across frames—an area where earlier models often fell short.
Source: Venkatarangan in Andaman, real picture
Output: AI-generated image of Venkatarangan with a winter jacket near Himalayas base camp.
I conducted a couple of tests to evaluate its capabilities:
📷 First, I took a photo of myself at home and asked the model to place me in a modern office in the U.S. The result? Decent—but it changed the camera angle, and I ended up with my back facing the camera, which wasn’t ideal.
🖼️ Next, I uploaded a selfie from an Andaman beach and asked it to transform the setting to the Himalayas, complete with a winter jacket. This time, the model delivered a highly realistic output—it genuinely looked like I had taken the photo in the mountains.
The Prompt I used in Google AI Studio
To try this, you’ll need a Google AI Studio account, which can be set up using your regular Gmail ID. Google provides a free trial within certain limits, so you can explore its capabilities firsthand.
This is an interesting development, but as with any AI model, it’s not perfect yet. The improvements in context understanding and image coherence are promising, but camera angles and finer details still need work. I’ll continue experimenting and share more insights soon.
Have you tried Gemini 2.0 Flash-Experimental yet? Curious to hear your thoughts!
I recently had to digitally sign an invoice for a client, and it got me thinking about how freelancers and small businesses handle this. Paper invoices are nearly extinct, and most transactions now happen through PDFs. Some enterprise clients require a digitally signed invoice for compliance, and if you don’t have the right tools, this can slow down your payment.
Over the years, I’ve signed plenty of contracts and agreements digitally—big enterprises typically send a link from their signing tools, and I just sign using it. But this was the first time a client specifically asked me to digitally sign an invoice.
Large companies typically use DocuSign, Adobe Sign, or Zoho Sign—all excellent services that comply with global digital signature standards, including eIDAS (EU), US Digital Signature Standards, and India’s IT Act. However, these are paid services, and if your signing needs are occasional, committing to a monthly subscription may not be necessary.
I use Zoho Invoice for my consulting and speaking engagements, and when a client asked for a digitally signed invoice, I remembered that Dropbox Sign (aka HelloSign) is included in my Dropbox subscription. I uploaded the invoice, signed it, and shared it in just a few minutes—quick, seamless, and at no extra cost.
Dropbox Sign (Hellosign)
For those in India, Zoho Sign is a great option since it explicitly supports Digital Signature Certificates (DSCs) from Indian Certifying Authorities (CAs) and Aadhaar eSign, making it fully compliant with the Indian IT Act. If you need something widely accepted across geographies, Zoho Sign, Adobe Sign, and DocuSign all comply with US, EU, and other digital signature regulations. Dropbox Sign, while convenient, does not explicitly mention compliance with the Indian IT Act, so it’s worth verifying before using it for official documents.
Comparison of Digital Signature Services
Feature
Zoho Sign
DocuSign
Adobe Sign
Dropbox Sign (HelloSign)
Microsoft 365 Sign
Legally Binding in India (IT Act, 2000)
✅ Yes
✅ Yes
✅ Yes
⚠️ Limited (Not compliant with DSC)
❌ No (Basic electronic signatures)
Legally Binding in US (ESIGN Act, UETA)
✅ Yes
✅ Yes
✅ Yes
✅ Yes
❌ No (Internal approvals only)
Legally Binding in EU (eIDAS Regulation)
✅ Yes
✅ Yes
✅ Yes
✅ Yes
❌ No
Supports Indian Class 3 DSC (Digital Signature Certificate)
✅ Yes (USB Token, PFX)
✅ Yes (Manual Upload)
✅ Yes (Adobe Acrobat)
❌ No
❌ No
Supports Aadhaar eSign (India)
✅ Yes
❌ No
❌ No
❌ No
❌ No
Tamper-Proof & Audit Trail
✅ Yes (Full logs, IP tracking)
✅ Yes (Detailed logs, IP tracking)
✅ Yes (Full audit trail)
✅ Yes (Basic logs)
⚠️ Limited
Certificate Authority (CA) Trust
✅ Indian & Global CAs
✅ Global CAs
✅ Global CAs
✅ Global CAs
❌ No
USB Token / Smartcard Signing
✅ Yes
✅ Yes
✅ Yes
❌ No
❌ No
Integration with Government Services
✅ MCA, GST, IT Returns (India)
❌ No
❌ No
❌ No
❌ No
Cloud-Based Signing
✅ Yes
✅ Yes
✅ Yes
✅ Yes
✅ Yes
Integration with Microsoft 365
✅ Yes
✅ Yes
✅ Yes
❌ No
✅ Yes (Internal signing only)
Integration with Google Workspace & Dropbox
✅ Yes
✅ Yes
✅ Yes
✅ Yes
❌ No
Best For
✅ Indian Businesses, Aadhaar eSign, MCA Filings
✅ Global Enterprises, Contracts, Legal Docs
✅ PDF-Based Signing, Global Compliance
✅ Dropbox & Google Users, Basic Signing
❌ Internal Approvals Only
Disclosure: The insights in this post are based on my personal experience and research. The comparison table below was generated using ChatGPT-4o and should be independently verified before making any purchasing decisions.
Bottom Line:
– Need a free and India-compliant option? Start with Zoho Sign.
– Enterprise-level security? Use Adobe Sign or DocuSign.
– Already paying for Dropbox? Try Dropbox Sign first.
Have you had to sign invoices digitally? What’s been your experience? Let’s discuss!
Footnotes:
How Digital Signature Services Work: These platforms verify your identity via email or SMS, then embed a digital key into your document to ensure it remains unaltered. For higher security, you can use a Digital Signature Certificate (DSC)—the same one used for Income Tax filings and corporate regulatory submissions in India. For high-value contracts, a Class 3 DSC is mandatory. For quick, everyday signing, Aadhaar eSign is a convenient option for Indian users.
A Quick Note on Microsoft 365: If you’re using Microsoft 365 on iOS or Android, there’s a basic signature tool under PDF Tools > Sign a PDF. However, this is just an image-based attestation, not a legally recognized digital signature.
Microsoft Word’s Digital Signing Feature: Microsoft Word does offer a digital signing integration, but since it’s not commonly used outside internal enterprise setups, I’m leaving it out here.
Abacus.AI’s recently introduced “Computer Agent”, part of their ChatLLM subscription. This represents a noteworthy step forward in simplifying computer automation. By far one of the most intuitive approaches I’ve seen, it functions like a simplified version of robotic process automation (RPA), but with the seamless ease of a chat interface. Currently, it operates within a virtual sandbox environment with limited applications, but the potential is clear and exciting.
The idea is straightforward yet powerful: you interact with your computer through natural language chat to complete tasks. For instance, you can ask it to browse the web, gather images, resize or recolor them, or even create a spreadsheet from online statistics. These are tasks that would traditionally require browser automation tools or shell scripts, but the “Computer Agent” lowers the technical barrier significantly. While I have yet to fully test its capabilities, it already appears capable of handling many routine automation tasks efficiently.
Abacus.AI’s “Computer Agent” simplifies image editing via chat commands
This development aligns with the trend pioneered by systems like Claude’s “Computer Use” feature, which debuted a few months ago. Both tools reflect a promising approach: using Generative AI to bridge the gap between human instructions and computer execution. It’s a vision where everyday users can automate repetitive workflows without the steep learning curve of traditional RPA or coding.
Imagine the possibilities if companies like Apple or Microsoft were to adopt and expand on this concept. Apple could move beyond the somewhat constrained “Shortcuts” app, and Microsoft could evolve its Power Automate platform to integrate more seamless, conversational automation. Such advancements could revolutionize productivity for millions of users, enabling them to delegate mundane tasks effortlessly, saving time and boosting efficiency.
A Promising Future, Despite Current Limitations
It’s important to acknowledge that this technology is still evolving. Today’s implementations are limited in scope and functionality, and challenges remain in ensuring reliability, security, and scalability. However, the potential is enormous. I believe that after the significant breakthroughs we’ve seen in text processing and image generation, this kind of natural-language-driven computer automation could become the next major real-world application of Generative AI.
As these tools mature, they hold the promise to redefine how we interact with computers, making automation accessible to all and transforming how we work, create, and innovate.
