About
An Ahmedabad engineering services company.
ASHNAY SOFTWARE is an engineering services provider and technology company, run as a proprietorship. We write firmware, embedded Linux, drivers, and application software for embedded systems and consumer-electronics products. Projects are taken and executed from Ahmedabad.
Who we are
We are just starting. There is no client list on this site, no partner wall, and no award shelf — we have not invented any. We take software work we can stand behind, and we are explicit about the work we will not take.
We work as an engineering counterpart on the software side of a product. The people we write for already have hardware, or they have a hardware partner. Our work is the code: firmware, embedded Linux, drivers and connectivity, embedded GUI, and application software.
We speak to engineering counterparts. We write what we will do, what we will not do, and how we will hand the work back.
Principal
Arpan Patel · Proprietor, ASHNAY SOFTWARE
Arpan Patel is the proprietor and principal of ASHNAY SOFTWARE. The company’s work is firmware and platform software he writes — not a marketing summary. He has more than fifteen years of shipped embedded software and more than forty products in the field: 15+ years and 40+ products as his professional record, not as the age of the company.
The class of work:
- Embedded GUI and display firmware (LVGL-class stacks; Qt for MCUs and STM32 TouchGFX when a target calls for the comparison)
- Android BSP, with CTS, VTS, and Play Protect as a release gate
- Yocto images and kernel CVE patching on a release train
- Device firmware for products already in the field: OTA, BLE GATT, power-state handling, and the software around a DSP already on the part
- Device drivers, including schematic and datasheet reading to bring a peripheral up
- Client-facing delivery: requirements, software design, escalation, and ODM / JDM firmware coordination
Languages and internals that show up in that work:
- C/C++, FreeRTOS, Zephyr
- Android internals (HAL, Camera, platform frameworks, native)
- Linux kernel, USB, I2C, SPI, TCP/IP
- Shell and Python when the image or the test needs it
That is the practice. It is not a personal directory, and it is not a company history.
What we are not
We are not a shop. We are not a hardware house. We do not design boards, capture schematics, design enclosures, manufacture devices, run a hardware lab, design camera modules, design silicon, FPGAs, or ASICs, or sell finished devices. We do read schematics and datasheets to write and bring up drivers. That is software.
- Printed-circuit design, schematic capture, or layout — we read a schematic to write a driver; we do not draw one
- Enclosure or mechanical design
- Manufacturing, tooling, or a production line
- Hardware lab services, or hardware board bring-up as a product
- Camera-module design
- Silicon, FPGA, or ASIC design
- Selling devices, boards, or modules
If the work is the board, the box, or the factory, we are the wrong company. If the work is the software that runs on a product you own, that is the conversation we want.
How we work
You own the hardware. We need access to a target — or a faithful stand-in you provide — to implement and test. We do not take ownership of your design files, your supply chain, or your manufacturing. The sequence is software only. Delivery is from Ahmedabad.
We follow a software development life cycle (SDLC). Delivery can run Agile or Waterfall — we choose the method that fits the engagement, not a house doctrine. Generative AI is a tool we use in the engineering process. It is not a product we sell, and it is not a claim that the work is fully automated.
Practices
Software development life cycle
Work follows an SDLC: we write the software problem, design the software, implement it, test it on a target you supply, and hand it off so another engineer can continue. The steps below are that cycle. They are not a certificate and not a branded method of ours.
Agile or Waterfall
Delivery can run Agile or Waterfall. We choose the cadence that fits the engagement — a written baseline and a single drop when the requirement is already closed, or a sprint and a review when it is still moving. We do not pretend there is only one way.
Generative AI as a tool
We use generative AI in the engineering process: drafting, exploration, and review against a problem we already understand. It is a tool in the work. It is not a product we sell, not a vendor badge, and not a claim that delivery is automated. We still write, review, and stand behind the software.
The sequence
01
Discover
We write down the software problem: the target you have, the interfaces that already exist, the constraints (memory, power, timing, update), and what this release must do. We do not begin by redesigning the hardware.
02
Software architecture
We partition the software: what belongs in firmware, what belongs in Linux userspace, which interfaces the application owns, and how those pieces meet. The architecture is a software document. It is not a schematic.
03
Implement
We write and integrate the software against the hardware you supply or specify. We need a target, or a stand-in you provide. We do not fabricate one. We will read the schematic and the datasheets to write drivers.
04
Test
We exercise the software on the target you provide and report what we ran and what failed. This is software test, not a hardware qualification lab.
05
Handoff
We deliver source, build notes, and the context another engineer needs to continue. You keep the hardware, the design files, and the product.
Where
The registered office is in Ahmedabad. Projects are taken and executed from Ahmedabad. We do not claim other offices.
A-401 Saral PariveshIOC Road, ChandkhedaAhmedabad 382424Gujarat, India- Phone
- +91 90607-01455