--- title: Kenuba Astro Phase 2 case study description: "How Kenuba Astro Phase 2 launched an astrology consultation platform on the Custom build base, with 17 of 21 blocks reused unchanged and 4 built for them." url: https://miracuves.com/portfolio/kenuba-astro-phase-2 date_modified: 2026-08-19 author: miracuves language: en_US --- Case study* · 2025* # An astrology consultation platform built from the data model up. Kenuba Astro Phase 2 needed an astrology consultation platform. There was no proven base that fitted, so it was designed and built to their specification, with a fixed quote after a free feasibility study. - **Custom build** · NO BASE - **2 to 8 weeks** custom build window - **Source code transferred** to Kenuba Astro Phase 2’s own account [Read the case study](#summary) [Start a project](https://miracuves.com/schedule-consultation/) *KA***Kenuba Astro Phase 2***Kenuba Astro Pvt. Ltd* *KA***Kenuba Astro Phase 2** SolutionCustom build ProductNO BASE Delivered2025 StackSTACK CHOSEN PER PROJECT · NO INHERITED BASE Build time2 to 8 weeks Blocks reused17 of 21 Source codeTransferred **3**applications shipped **17**blocks reused unchanged **4**built for this client **6**integrations, each isolated **100%**source code transferred ## What already existed, and what did not. Every layer of this one was built for Kenuba Astro Phase 2. The only shared floor is how it was deployed and handed over. We build the product; the client launches the brand. That is the arrangement, and it only works if the handover is real: Kenuba Astro Phase 2 owns the source code, had a launch date in writing before work started, and can check every figure on this page against a public ledger. We looked for something ready-made and there was not one. It was designed from the ground up for us - an astrology consultation platform that does what we actually needed, with the code handed over at the end. Clide Higake, Founder · Kenuba Astro Pvt. Ltd Reuse on this build Blocks reused17 of 21 Built for Kenuba Astro Phase 24 Solution familyCustom build Other builds on it17 ## The line between reused and built. The work sat where it always sits on this base: data model, domain logic, services & apis. Everything else on the list below arrived already built and proven on other engagements running the same base. **3**Applications and consoles shipped, each with its own permissions and release path*Delivered* **17**Platform modules reused unchanged from the Custom build base*Delivered* **4**Decisions built for Kenuba Astro Phase 2: data model, domain logic, services & apis*Delivered* **3**Environments: development, staging and production*Delivered* **100%**Source code transferred to Kenuba Astro Phase 2’s own account*Contractual* ## What Kenuba Astro Phase 2 actually needed. An astrology consultation platform is not one feature. It is 21 distinct pieces that all have to work together before a single customer can be served, and none of them existed yet. That distinction decides the shape of a project like this. A business does not need a dispatch engine or a settlement ledger to be invented again; it needs one that already works, then it needs the handful of decisions that make the product theirs rather than anyone else’s. The four below are the load-bearing pieces Kenuba Astro Phase 2 would otherwise have spent months building before proving anything to a customer. Every platform of this kind has the same shape underneath: a set of load-bearing parts that must be correct before a single customer can be served, and a much smaller set of decisions that make it one business rather than another. Building the first set from zero would have consumed the window before the second was even discussed. That is the decision this engagement turned on, and it was taken before any code was written. **Customer surface**the journeys you specified **Operator surface**the internal tools you **System integrations**the systems you already **API gateway**auth, rate limits, ## What we settled before building. With no base to inherit, the first work was agreeing the data model and the rules that govern it. Where a scope genuinely does not fit a proven base, we say so during scoping and quote it as a custom build instead, even when that costs us the larger and more comfortable project. *01* #### Read the requirement back to first principles What must exist at launch, separated from what a business can add once it has customers. Those are different lists and conflating them is what makes projects run long. *02* #### Base versus build, capability by capability Each of the 21 capabilities assessed against the existing base as covered, partial or absent. Partial is treated as absent, because a half-fitting module costs more than a new one. *03* #### Mark what only Kenuba Astro Phase 2 could decide 4 decisions were commercial or jurisdictional rather than technical. Those were theirs, and the engagement is where they got implemented. *04* #### Agree the line before writing anything 17 pieces reused unchanged, 4 built. Fixing that line up front is what turns a platform of this size into a two-to-eight-week build. ## The parts that are genuinely hard. Not marketing difficulty, actual difficulty. These are the problems any serious Custom build has to solve properly, and the reason building one from a blank page is a multi-quarter commitment rather than a sprint. On a custom build these are solved from scratch, in sequence, which is why the window is two to eight weeks rather than six days. 01 ### No proven base to inherit Every assumption has to be made explicit and agreed, because nothing upstream has already decided it. **Built for this project:** Customer surface 02 ### The data model is the commitment Get the entities and rules wrong and every later decision inherits the error. **Built for this project:** Operator surface 03 ### Scope discipline Without a base, scope is the only thing holding the timeline. That is why custom work is quoted after a feasibility study. **Built for this project:** System integrations ## Why Kenuba Astro Phase 2 was specified from a blank sheet. No proven base fitted the shape of this product, so the whole of it was specified and built. Here is the account of that, part by part. We looked for a proven base first, the way we do on every engagement. Nothing on the shelf carried the rules this product runs on, and a base that half fits costs more to bend than a clean specification costs to write. So Kenuba Astro Phase 2 was specified and built end to end, over 2 to 8 weeks. What that bought is a system with nothing inherited in it. Every part answers to this product's own rules rather than to assumptions made for somebody else's, so there is no layer that has to be worked around later. **Specified and built***4 of 21* *01***Data model**the entities and their *02***Domain logic**what the business *03***Services & APIs**how the parts talk *04***Interfaces**what your people and Bend a base that was never shaped for this Built to this product's own rules, in 2 to 8 weeks The account Specified and built4 Parts in total21 Build window2 to 8 weeks Nothing here was inherited. Every part was written for this product. ## What this market demanded. With no proven base, the market question is answered in the data model itself, because nothing upstream has already made those assumptions. None of that is optional, and none of it is something a platform can guess on a client’s behalf. It is precisely why the 4 decisions listed further down sat with Kenuba Astro Phase 2 rather than with us: they are commercial and jurisdictional questions, and the base exists so that answering them is the whole job rather than the last ten per cent of it. ## Everything that shipped with it. The full working set Kenuba Astro Phase 2 took delivery of. Each piece was already built and proven on other engagements before this one started, which is the only honest reason a platform of this size stands up in weeks rather than quarters. None of it is a demo or a scaffold. These are the same components running under other businesses in other markets, which means the failure modes are already known and already handled rather than waiting to be discovered by Kenuba Astro Phase 2’s first real customers. ### Reused from the Custom build base **Customer surface**the journeys you specified **Operator surface**the internal tools you **System integrations**the systems you already **API gateway**auth, rate limits, **Integration layer**adapters to your **Event bus**async fan-out, retries **Audit trail**append-only record of **Environments**dev, staging, production **Deployment**pipelines, rollback **Monitoring**logs, alerts, uptime **Handover**source, docs, **Identity & access**accounts, roles, **Secrets & config**per-environment keys **Backups & restore**snapshots, tested **store**the schema designed **realtime**sessions, queues, **Object storage**uploads, exports, ### Built for Kenuba Astro Phase 2 **Data model**the entities and their **Domain logic**what the business **Services & APIs**how the parts talk **Interfaces**what your people and ## The base this was built on. The same architecture carries every Custom build on this page. The filled blocks are the parts built for Kenuba Astro Phase 2. **Custom build architecture** NO BASE / filled = built for this client This is the Custom build base, drawn as it was actually assembled for Kenuba Astro Phase 2. The plain blocks are the ready-made platform and shipped as they are. The filled blocks are the ones we built for this client. 17 of 21 blocks were reused, 4 were built. ## Why none of this had to be written again. Each of these was already running on other builds of the same base before Kenuba Astro Phase 2 started. That is the whole reason the platform was standing in weeks rather than months. **Customer surface**the journeys you specified **Operator surface**the internal tools you **System integrations**the systems you already **API gateway**auth, rate limits, **Integration layer**adapters to your **Event bus**async fan-out, retries **Audit trail**append-only record of **Environments**dev, staging, production **Deployment**pipelines, rollback **Monitoring**logs, alerts, uptime **Handover**source, docs, **Identity & access**accounts, roles, **Secrets & config**per-environment keys **Backups & restore**snapshots, tested **store**the schema designed **realtime**sessions, queues, **Object storage**uploads, exports, ## The decisions that were actually theirs. A ready-made base does not remove these; it removes everything underneath them. Each one below is a choice Kenuba Astro Phase 2 had to make, and the engagement is where those choices got implemented. ### Data model Configured for Kenuba Astro Phase 2 during the engagement. **Why it sat with them**Commercial rather than technical. The base already handles the mechanics underneath, so the engagement is where their own answer gets implemented. ### Domain logic Configured for Kenuba Astro Phase 2 during the engagement. **Why it sat with them**Commercial rather than technical. The base already handles the mechanics underneath, so the engagement is where their own answer gets implemented. ### Services & APIs Configured for Kenuba Astro Phase 2 during the engagement. **Why it sat with them**Commercial rather than technical. The base already handles the mechanics underneath, so the engagement is where their own answer gets implemented. ### Interfaces Configured for Kenuba Astro Phase 2 during the engagement. **Why it sat with them**Commercial rather than technical. The base already handles the mechanics underneath, so the engagement is where their own answer gets implemented. ## How a custom build runs. With no base to start from, the sequence is the opposite way round: the data model first, interfaces last. 01 ### Data model The entities and the rules that govern them, agreed before anything is built. 02 ### Domain logic What the business actually does, expressed once and tested. 03 ### Services & APIs How the parts talk, and what the contract between them is. 04 ### Interfaces What the client’s people and customers use, built last on a settled core. The client supplies the hosting and domain, a verified developer account we publish from, branding and business details, an onboarded payment gateway with KYC complete, and any third-party API keys. Store review and merchant onboarding are controlled by Apple, Google and the payment provider, so those sit outside our window. [Every figure here is defined on the facts page](https://miracuves.com/facts/#fact-005). ## Who uses it, and for what. Rather than screenshots of a product that has moved on since delivery, this is the set of surfaces that shipped and what each one is for. Kenuba Astro Phase 2 received every one of them, with the source behind each. Every role here is a separate application with its own permissions, its own state and its own release path. Building them to work as one system is most of the engineering in a platform of this kind, and it is the part that was already finished before this engagement began. the journeys you specified the internal tools you the systems you already ## What guards the platform. Built into the base and hardened across every engagement running it, rather than bolted on at the end of this one. Security added late is security that has to be argued for; the controls below were load-bearing from the first deployment. We claim the process, not a certificate. Miracuves does not hold ISO 27001, and we do not say otherwise: we build to the controls those frameworks require, and the evidence trail is there for an auditor who asks. #### Identity & access accounts, roles,. Part of the base, so it was proven before this engagement started. #### Role separation Each surface sees only what its role permits, enforced server-side rather than hidden in the interface. #### Audit trail Who changed what and when, retained so a dispute can be answered with a record rather than a recollection. #### Transport and storage TLS end to end, credentials hashed, and anything sensitive at rest encrypted rather than merely obscured. #### Secrets handling Keys live in environment configuration on their own infrastructure, never in the repository we hand over. #### Card data stays out Payment details go to the gateway directly. The platform holds a reference, not a card number. #### Backups and restore Scheduled backups with a restore that was actually run, because an untested backup is a guess. #### What an auditor can actually see We claim the process, not a badge. Everything below was handed to Kenuba Astro Phase 2 with the source. - Commit history for every change in the build window - Environment configuration separated from application code - Database schema with the migration that produced it - Deployment steps written down rather than remembered - Named team and a daily written progress record ## What it connects to. The connection points are part of the base and were already written and tested. Which providers sit behind each one was Kenuba Astro Phase 2’s decision, because those choices are commercial and jurisdictional rather than technical. This is also where the client-side dependencies live. Gateway onboarding, KYC approval and merchant review are controlled by the provider, not by us, which is why they sit outside the build window rather than inside it. Every one of these was already wired and tested in the base. What changed for Kenuba Astro Phase 2 was which account sat on the far side of it. **Identity and KYC**provider per jurisdiction **Object storage and CDN**their bucket, their region **Media pipeline**transcode and delivery **Market data feeds**rates and reference prices **Push and transactional email**sent under their sender identity **App store developer accounts**published from their own accounts ## What it runs on. The platform stack for NO BASE. This describes the base as it stands today; Kenuba Astro Phase 2 took delivery of the source and has owned it since. **Platform**STACK CHOSEN PER PROJECTNO INHERITED BASE The stack the NO BASE base runs on, already in production elsewhere **Surfaces**Customer surfaceOperator surfaceSystem integrations Each a separate application with its own permissions and release path **Client decisions**Data modelDomain logicServices & APIsInterfaces Configured for Kenuba Astro Phase 2 during the engagement **Handover**SourceSchemaDeployment configArchitecture notes Transferred at the end of the build ## How the weeks were spent. Our build time only. Store review and merchant onboarding are controlled by Apple, Google and the payment provider, so they sit outside this window and we do not count them as ours. Stating that plainly is the difference between a build time and a promise we cannot keep. [Every figure here is defined on the facts page](https://miracuves.com/facts/#fact-005). Custom builds get a fixed quote after a free feasibility study. No open-ended timelines, and no scope creep arriving in the invoice. Throughout, a named team worked the build and sent Kenuba Astro Phase 2 progress on WhatsApp every working day. There was never a week where nobody knew where it stood, which is the part clients tell us they notice more than the date itself. **2 to 8 weeks** our side of the window The bar below is that window, day by day. Nothing outside it is counted as ours, and nothing inside it waits on someone else. #### What Kenuba Astro Phase 2 supplied A build window only holds if both sides arrive ready. These sat with them, and the clock does not start until they are in place. - Hosting and a domain, on their own account - A verified developer account we publish from - Branding and business details - A payment gateway onboarded, with KYC complete - Third-party keys for the services they chose **Weeks 1-2**Data model and domain rules agreed*Data model and domain rules agreed* **Weeks 3-5**Services and APIs, then the interfaces*Services and APIs, then the interfaces* **Weeks 6-8**Hardening, environments, handover*Hardening, environments, handover* ## This base has done this before. Kenuba Astro Phase 2 was not the experiment. The base underneath this build had already carried other businesses in other markets before it carried theirs, which is the whole argument for reuse: the risk was retired by somebody else’s project, not by this one. Across everything delivered since 2010 that is more than 9,000 products for over 6,000 businesses across 35+ industries. The eighty-four documented on this site are the ones with a named client and permission to show the work; most of the rest sits under NDA or white-label and is deliberately not here at all. Every number on this page is defined and sourced on a public facts ledger. That is the whole instinct behind how this company is run: most vendors ask you to trust them, and we would rather you checked us. If we cannot back a claim, we do not make it, which is why you will not find a satisfaction percentage or an unnamed award anywhere on this site. **17 of 21** Blocks reused unchanged on this build, each already under load on other engagements. *Architecture* **18** Documented builds running on the Custom build base, in different markets. *Portfolio* **9,000+** Products delivered for more than 6,000 businesses across 35+ industries since 2010. *Company record* **3,900+** Apps published under clients’ own brands, counted per store release. *Company record* ## What we can state plainly. No client figures were supplied for this build, so these are architectural and contractual facts rather than outcomes. **Source code transferred** blocks reused unchanged Full repository history, to the client’s own account Miracuves delivery record **6 working days**Our build time on the ready-made base **2 to 8 weeks**Our build window on this engagement.Miracuves delivery record **100%**Source code transferred to Kenuba Astro Phase 2’s own account.Contractual > We looked for something ready-made and there was not one. It was designed from the ground up for us - an astrology consultation platform that does what we actually needed, with the code handed over at the end. > > > **Clide Higake**Founder, Kenuba Astro Pvt. Ltd ## What Kenuba Astro Phase 2 holds now. The same on every engagement. What happened to the platform after handover was theirs to decide. *GIT***Application source**Full repository history, transferred to their account*Delivered* *APP***Mobile projects**Sources with signing documented*Delivered* *SQL***Schema and migrations**Reproducible from empty, not a dump*Delivered* *ENV***Deployment configuration**Another team can run it unaided*Delivered* *MD***Architecture notes**What was chosen, what was rejected, why*Delivered* *60d***Support window**Sixty days included, six and twelve month options*Delivered* ## The questions that decide this. Answered for this build. The same answers hold for every Custom build in the portfolio. Do we own the code? Yes. The full repository history transferred to Kenuba Astro Phase 2’s own account at handover, with deployment configuration and architecture notes. It is not a licence and it is not held against a support contract. How is two to eight weeks realistic? Because the sequence is disciplined: data model first, interfaces last. Nothing is built twice. What sat with Kenuba Astro Phase 2? Hosting and domain, a verified developer account we publish from, branding and business details, an onboarded payment gateway with KYC complete, and any third-party API keys. Will it look like everyone else’s? No. The base supplies mechanics, not identity. Branding, flows and every customer-facing screen were built for this product. Is this what the platform looks like today? This describes what was delivered in 2025. What happened afterwards was Kenuba Astro Phase 2’s to decide; the source transferred at handover. Clients move on, rebuild, or sell up, and none of that changes what was delivered or how it went. Would you have said no to this project? We are a good fit for a founder who wants a proven model launched fast, a deadline they can hold us to, and code they own outright. We are a poor fit for anyone who needs a team embedded in their office full-time, or who wants a blank page and a six-month roadmap. Being straight about that up front saves everyone a call. Who actually worked on it? A named team, not a rotating pool. Our leadership is public with real profiles rather than a stock-photo team page, and progress went to Kenuba Astro Phase 2 on WhatsApp every working day of the build. ## Others on the same base. Different clients, different markets, one proven platform underneath. [**CarrSync**Custom build - a vehicle logistics platform](/portfolio/carrsync/) [**Coachs Online**Custom build - a coaching marketplace with live sessions](/portfolio/coachs-online-edu-app/) [**Dermacian Website**Custom build - a custom clinic website](/portfolio/dermacian-website/) ## Where to go from here. The service and the industry behind this build. [**Custom software development**The service behind work like this](https://miracuves.com/service/software-development/) [**Professional and on-demand services**How we build for this industry](https://miracuves.com/industries/professional-on-demand/) ## Building something like this? Tell us what you are building and we will say plainly whether a ready-made base fits it, including when the answer costs us the larger project. [Book a technical call](https://miracuves.com/schedule-consultation/) [See all case studies](/portfolio/) - Ready-made platform deploys in 6 working days - Custom builds run 2 to 8 weeks - Source code transfers on every engagement - [Every figure here is defined on the facts page](https://miracuves.com/facts/#fact-005) ## Disclaimer **Miracuves is an independent software development company.** We are not affiliated with, connected to, sponsored by, or endorsed by any of the brands or platforms named on this page. Names of the form “Brand Clone” are used descriptively: it is how the software industry refers to building a platform with functionality comparable to a known service, and how clients search for it. The entire design and codebase of our products is built by our own team and contains no code, design, graphics, or content originating from any third-party website or application. All third-party names and marks are the property of their respective owners. [Full Legal Notice & Disclaimer](https://miracuves.com/disclaimer/)