A good developer should sometimes make your project smaller

If I hire a senior developer, I expect them to talk me out of some of the work. A proposal that accepts every feature and adds a service for every problem can look thorough. It can also leave the business with an expensive system to operate.

That is why a recent Laravel engineering post caught my attention. It described a useful technical decision that rarely gets the same applause as a launch: removing something the team had just built.

The part they took out

In a September 3 account of Laravel Boost’s project rules, Pushpak Chhajed described building a semantic search layer, then removing it five days later. For a small collection of conventions, ordinary Markdown files, a generated index and text search were a better fit. The author reports more consistent rule lookup in exploratory testing and explicitly says a controlled comparison is still needed.

This was a decision about one feature. Boost’s separate documentation search still uses embeddings. The same product can sensibly use a sophisticated search system in one place and plain files in another.

I like the judgment in that. The team had a specific job to do, and the first design asked them to maintain more machinery than the job warranted.

The maintenance work comes with the diagram

Consider a hypothetical business with a small internal tool and forty procedure documents. Employees need to find the right returns policy or installation checklist. A proposal arrives with a separate search service, an embedding pipeline, a synchronization worker, another dashboard and an AI chat interface.

Any of those pieces might earn its place. Before buying the whole arrangement, I would want to see which questions the existing system cannot answer.

Perhaps the documents have inconsistent names and no clear owner. Perhaps the search box ignores the reference numbers employees actually use. Perhaps obsolete instructions appear beside the current version without a date. A new model will not decide who is responsible for approving the returns policy.

Each extra service creates work beyond the first implementation. Someone has to manage its credentials, monitor failures, handle upgrades and know how to recover it. When the original document changes, a second copy or search index may need updating too. That creates a period in which two parts of the system can disagree.

Managed services can take substantial operational work off your hands. They still need an owner in your application: someone who understands the configuration, the bill and what users experience when the dependency is unavailable.

Make the simpler option prove itself

I would start the search project with a small set of real employee questions and the documents that should answer them. Include an exact product code, an old policy name, a question phrased in the employee’s own words and a document that employee must not be allowed to read.

Use that set to compare the current tool, an improved conventional search and any proposed AI-assisted version. Record whether the right material appears, whether it is current, how long the task takes and whether restricted material stays restricted. A small trial helps choose a direction; it does not replace a proper access-control review or testing at the expected load.

There may already be useful search capability in the database you operate. PostgreSQL’s full-text search, for example, supports indexing, word normalization and ranking. It is more capable than checking whether a paragraph contains an exact string. That makes it an option worth evaluating, without assuming it will suit every language or collection.

If employees use very different wording from the documents, retrieval by meaning may help. If the system has to combine information from several sources, the design may need to go further. Those are reasons to test a more capable approach against the same questions and constraints.

Even then, choosing vector search does not automatically mean choosing another database service. pgvector adds vector similarity search to PostgreSQL. Its documentation also makes a useful tradeoff explicit: approximate indexes can exchange some recall for speed. Hosting support, workload, isolation and operational needs still determine whether that is an appropriate option.

The goal is to learn which design meets the requirement with an operating burden the business can support. Counting boxes on the architecture diagram will not answer that.

Ask what makes the next layer necessary

A useful proposal should say what would cause the simpler design to stop being enough. That might be a measured response-time limit, a search-quality target it cannot meet, an isolation requirement or a workload that needs independent scaling.

Ask for the evidence behind that boundary. “We will need it when we grow” leaves too much unspecified. A forecast of document volume, concurrent users and acceptable response times gives the team something to design and test against. If those numbers are unknown, say so and allow for measurement.

It can be worth paying more now when a later migration would be unusually disruptive. It can also be reasonable to accept a modest manual step in a tool used twice a month. The decision depends on the work, the consequences of failure and the people available to run it.

Remove responsibilities carefully

Simplifying an existing application takes investigation. Before removing a component, establish who uses it, what data it owns and which reports or background jobs depend on it. Preserve the behavior people need, verify the replacement and plan a rollback before switching traffic.

Authentication, validation, backups and useful audit records still have jobs to do. Moving everything into one unstructured file would make a diagram smaller while making maintenance worse. Clear boundaries inside an application can be valuable without turning every boundary into a separately deployed service.

For a business owner reviewing a proposal, I would ask the developer to explain one component they chose to leave out and what would change that decision. A clear answer tells you something about how they think about your budget and your future maintenance work.

If your application has accumulated services that nobody can explain, Rosecraft offers technical assessment and planning. We can examine the existing workflow, identify the dependencies that serve it and recommend a scoped next step. Tell us what the system does and what has become difficult to maintain.