Solfreaks CloudCore API covers the server side of apps and websites: the REST or GraphQL API, the database behind it, and the background jobs that send emails, take payments and tidy up after users. A good backend is invisible. A bad one makes every screen in the app feel slow or broken.
We mostly work in Node.js with NestJS, in Laravel, or in Python with FastAPI, on top of PostgreSQL or MySQL. The stack matters less than the habits: a written API contract, useful error messages, tests around anything involving money or identity, and nothing clever that the next developer has to decode.
What the finished backend gives you
- The API itself, REST by default and GraphQL when your screens genuinely benefit from asking for exactly the fields they need.
- OpenAPI documentation generated from the code, so the docs can't drift away from what the server really does.
- Authentication and permissions with JWT access and refresh tokens, sign-in with Google or Apple through OAuth, and role checks on the server instead of in the app.
- Database design in PostgreSQL or MySQL, with migrations and indexes for the queries you really run.
- Queues and webhooks for slow or unreliable work such as notifications and payment callbacks, with retries that never charge a customer twice.
- File storage on S3-compatible storage with signed upload and download links, so large files never pass through your application server.
- Logging, error tracking and rate limiting so you can see what failed and one noisy client can't take the server down.
What makes an API pleasant to work with
App developers judge an API by small things. Consistent naming. Errors that say which field was wrong. Pagination that behaves the same on every list. Docs with real example responses, and a staging server full of test data they can break freely.
Then there's versioning. A mobile app can't be force-updated overnight, so people will run version 1 for months after you ship version 2, and the server has to keep answering the old requests. We plan for that from the first endpoint, and prefer adding fields to renaming or removing them.
Growing without over-building
On day one we usually recommend one well-organised application and one database, not a fleet of microservices. A cache goes in when measurements show a slow endpoint, a queue when jobs start piling up, and anything gets split out only when a real bottleneck appears.
We do plan ahead for the few things that are painful to retrofit: tenant IDs if you'll serve several customers, an audit trail, sensible indexes and a clean way to run database migrations. Deployment can sit on the DevOps and CI/CD setup we build alongside.
How a build goes
- Contract first. We write the endpoint list and OpenAPI spec with your app team before any server code, usually within the first week, so mobile and web developers can start against a mock.
- Schema and skeleton. Database design, authentication, logging and an empty but deployable project on staging, typically a few days of work.
- Build in slices. Feature by feature, with tests on the risky parts, released to staging about weekly so the app team integrates as we go.
- Break it on purpose. Before launch we test slow queries, payment callbacks that arrive twice, and what happens when a third-party service is down.
- Launch and watch. Go-live with monitoring switched on and close attention to the first real traffic, then handover: repository, docs and a walkthrough.
Who needs a custom backend
It fits app owners who have screens but no server, teams whose backend was written by one freelancer and now nobody dares touch it, and businesses that need to expose internal systems to partners through an API. For the inherited-code case we audit first and tell you whether it's worth saving, much as we do in legacy app revamp work.
You can probably skip it if your app is a prototype with a handful of users. A hosted service such as Firebase or Supabase may cover that, cost less and get you moving sooner. We'll say so honestly, and you can move to a custom backend when the app outgrows it.
Pricing and timeframes
Price is driven by the number of entities and endpoints, the integrations (payment gateways, SMS, maps, email), how complex login and permissions are, the traffic you expect, and any data migration. A defined API is a fixed-scope job; if development carries on after launch, a monthly arrangement fits better. Staff-facing screens can sit on the same API through our admin panel development.
A focused API for a single app usually takes four to eight weeks. A larger platform with several clients and many integrations more often takes three months or longer. Hosting bills go straight from the cloud provider to you. The quote follows a short discovery call.
Why us for the backend
The engineers who write your API are the people you speak to, since we're a small team working from Rawalpindi, next to Islamabad. Having shipped apps to Google Play, we know how an app behaves when it calls an API over a patchy mobile connection, and we build for that. Pakistan time overlaps with Gulf and UK working hours. The code, repositories and cloud accounts are yours. Tell us what you need and we'll set up a call.
Open-source tools and references
A few public projects that come up a lot in this kind of work. They belong to other people and teams. We link to them because they are worth a look, not because anyone pays us to.
- nestjs/nestStructured Node.js framework for APIs.
- fastapi/fastapiPython web framework for typed APIs.
- laravel/frameworkThe Laravel PHP framework.
- OAI/OpenAPI-SpecificationThe OpenAPI specification for describing HTTP APIs.
Frequently asked questions
How do you pick between NestJS, Laravel and FastAPI?
Mostly by who will maintain it. Laravel is quick for conventional business systems and has a large hiring pool. NestJS suits teams that already write TypeScript on the web or mobile side. FastAPI fits when the backend leans on Python, for example data work or machine learning. If you already have developers, we pick the stack they can read.
Do I need GraphQL, or is REST enough?
REST is enough for most apps and is simpler to cache, debug and document. GraphQL helps when many different screens need different slices of the same data, or when several client apps share one backend. It adds complexity on the server, so we recommend it only when the trade is worth it. It can also be added later if the need appears.
Can you take over a backend someone else built?
Yes, usually after a short audit of the code, the database and the servers. We look for security gaps, missing backups and anything that only works because of undocumented steps. Then we tell you whether to stabilise it, rebuild it piece by piece or replace it. Sometimes the old code is fine and only needs tests and documentation.
How do you keep older app versions working when the API changes?
We avoid breaking changes. New fields are added rather than renamed or removed, and new behaviour goes behind new endpoints or a version prefix. We track which app versions are still in use and retire old endpoints only when usage has dropped and users have been prompted to update. Mobile apps make this essential, because you can't force every phone to update at once.
Who owns the code, the servers and the data?
You do. The repositories live in your account, the cloud and database accounts are in your name, and we work with limited access that you can revoke at any time. We document how to run and deploy the system so another developer can take over without us. Third-party services we connect keep their own terms.
Talk it through with us
Tell us what you are building and where it hurts. You get a straight answer, a plan and a price, and if we are not the right people we will say so.
